Re: Extending protected types in 9X.

[news.bu.edu!inmet!spock!stt@decwrl.dec.com (Tucker Taft)]

In article <CBvrzz.LF7@zeno.fit.edu> 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