From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_05 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 23 Aug 93 17:00:08 GMT From: news.bu.edu!inmet!spock!stt@decwrl.dec.com (Tucker Taft) Subject: Re: Extending protected types in 9X. Message-ID: List-Id: In article woodward@cs.fit.edu (Bill Woodward) writes : >I've found the following references from the Ada 9X AARM version 2.0 that >seem to preclude type extensions for protected types. > >First, let's start with the syntax for a derived type: > > derived_type_definition ::= NEW subtype_indication [record_extension_part] > (AARM 3.4 p2; page 3-18) > > A record_extension_part shall be provided if and only if the parent type > is a tagged type. (AARM 3.4 p4; page 3-18) > > A record type or private type that has the reserved word TAGGED in its > declaration is called a tagged type. (AARM 3.9 p2; page 3-62) > >Is this correct? and if so Why? (my personal quess is that it would be an >implementation headache to allow type extensions for protected types). We considered allowing extension of protected types. We actually came up with a reasonable definition of how it would work. However, we decided against this as it imposed a certain amount of "distributed overhead" even in cases where no extensions existed, and (more importantly) it violated one of the important principles associated with monitor-like constructs such as protected types, that all of the critical sections associated with a given object are gathered together in a single file to ease analysis of correctness and deadlock freedom. Furthermore, the semantic description got quite complicated and somewhat non-intuitive due to the rules regarding "servicing the entry queues" which takes place immediately prior to unlocking a protected object. By the way, let me take this opportunity to comment on notions that one can simply "inherit" concurrency and persistence. This sounds all well and good in theory, but rest assured that it is hardly trivial. It is true that the Ada-based language DRAGOON did manage to define a kind of concurrency-behavior inheritance, but it is quite complicated, and can only be done at a leaf of an inheritance tree, not somewhere in the middle. The conflict here is that when defining mutual exclusion properties, one typically has to look at and analyze all of the relevant operations. On the other hand, one of the principles of inheritance is independent extension of properties in various dimensions. These two goals tend to conflict. If one is only going to define concurrency behavior at the "leaf" then approximately the same thing can be accomplished in Ada 9X by having an abstract root type, with multiple extensions each of which enforces its own mutual exclusion as it sees fit, using one or more protected objects as components. This I would call the "building block" approach (which is the fundamental philosophy of Ada 9X), rather than the "build-it-all-in" approach where the compiler and the language designer get very involved in anticipating and building in support for all of the kinds of properties that a user might want to be inheritable. As far as simply inheriting "persistence," it is a "persistent" (;-) myth that one can in general add persistence via simple inheritance. Certainly one can add some additional "persistence" interfaces by inheritance, but one still has the hard work of implementing all of the flattening and reconstructing operations for each type that inherits the "persistence" interfaces. Ada 9X defines and allows the user to override 'Read and 'Write attributes for this purpose. In any case, inheritance is actually contributing relatively little to such a situation. >Bill Woodward Florida Institute of Technology >woodward@se.fit.edu Melbourne, FLORIDA S. Tucker Taft stt@inmet.com Ada 9X Mapping/Revision Team Intermetrics, Inc. Cambridge, MA 02138