Re: Extending protected types in 9X.

Re: Extending protected types in 9X.

[agate!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!ne]

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.
> 

Oh, how I love a straight man :-)

>[deletia]

>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).
>

As Tucker may vouch, this is my favorite subject.  Colin Atkinson
and I have written a paper on this very subject.  It will be
published in the proceedings of Tri-Ada '93 (look for it in your
local bookstores soon!   NOT!).  

The Reader's Digest version is:  No, protected types cannot be
extended.  Nor can tagged types become "protected".  While it
is true you may nest one kind of type within the record structure
of the other, you fail to acquire the implicit benefits of that
nested type.  If you spend a little time on it, you can see that
extending protected types (or protecting tagged types) can turn into a
small concurrency nightmare.  However, protected types were not
really intended to be used in this manner (they were primarily
intended for small, shared regions of memory that would be accessed
by several tasks concurrently).  

We have proposed a syntax that will (ok, should) solve the problem
of protecting extended types.  We intend to tinker with the GNAT
compiler to include this new syntax, flesh it out, then annoy
people by banging our shoes on the table and insisting it be
part of Ada 0X.  It should be great fun. :-)  Alas, our proposal,
submitted a little under a year ago, was too late to be seriously
considered for inclusion in the Ada 9X language.



-- 
type My_Disclaimer is new Standard.Disclaimer with record
	AJPO, SEI : Cognizance := Disavow_All_Knowledge;
end record;--)

Re: Extending protected types in 9X.

[eng.ufl.edu!usenet.ufl.edu!zeno.fit.edu!woodward]

In article <1993Aug17.072336.21830@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David
 Weller) writes:
>As Tucker may vouch, this is my favorite subject.  Colin Atkinson
>and I have written a paper on this very subject.  It will be
>published in the proceedings of Tri-Ada '93 (look for it in your
>local bookstores soon!   NOT!).  
>
Any chance you could Email me a copy of your paper? I'm currently looking into
the improvements in Ada9X such as tagged types and protected types and I
would be interested in your views.

>The Reader's Digest version is:  No, protected types cannot be
>extended.  Nor can tagged types become "protected".  While it
>is true you may nest one kind of type within the record structure
>of the other, you fail to acquire the implicit benefits of that
>nested type.  If you spend a little time on it, you can see that
>extending protected types (or protecting tagged types) can turn into a
>small concurrency nightmare.  However, protected types were not
>really intended to be used in this manner (they were primarily
>intended for small, shared regions of memory that would be accessed
>by several tasks concurrently).  
>
But it would seem to be natural to extend some basic real time constructs
coded as protected types. Ex extend semaphores into counting semaphores
into mailboxes perhaps.


Bill Woodward				Florida Institute of Technology
woodward@se.fit.edu			Melbourne, FLORIDA

Plan:
with Knowledge_Learned;
use Knowledge_Learned;
procedure Graduate_ASAP(Teachings : IN Body_Of_Knowledge; 
                        Projects, Tests, Thesis : OUT Requirements) is ......

Re: Extending protected types in 9X.

[David Weller]

In article <1993Aug18.220747.1911@ennews.eas.asu.edu> koehnema@enuxsa.eas.asu.e
du (Harry Koehnemann) writes:
>In article <1993Aug17.072336.21830@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (Davi
d Weller) writes:
>>
>>The Reader's Digest version is:  No, protected types cannot be
>>extended.  Nor can tagged types become "protected".  While it
>>is true you may nest one kind of type within the record structure
>>of the other, you fail to acquire the implicit benefits of that
>>nested type.
>
>Bummer.  Inheritance of properties is a typical feature in OO
>languages.  If I want to be "protected", I'll inherit that property.

Not bloody likely.  Here's the problem: Inheriting "protection" (that
is, inheriting properties that ensure the instance will behave in
a concurrent environment) isn't as simple as adding a keyword (unless,
of course, you just want something like mutex applied to each
operation).  Concurrency control is _not_ a property, rather it
is some form of specification that dictates how each operation will
behave concurrently.  Further, such concurrency controls can't be
"sprinkled on" as you trudge along creating classes,
since you may want specific instances to behave differently.  Finally,
implementing a varied hierarchy of concurrency controls on top of
the usual dispatching algorithms is (IMHO) something akin to a
gordian knot made of kevlar.

>If I need to be extensible, I'll inherit the tagged (lovely name)
>property.  It is not enough for an OO language to inherit operations,
>we must be able to inherit all the properties of the thing we desire
>to become.
>

In comparison to other common "OO" languages, Ada 9X successfully
accomplishes this.  If you disagree, can you please elucidate?

>Does one even "inherit" an operation in 9X - instead, it appears we
>"gain type compatibility with" an operation.  I guess this comes
>from the type extension approach taken in Ada9X.  We must nest
>rather than inherit.
>

How's that again?  My "nesting" comment wasn't related to the current
9X type extension scheme.  I think the current scheme does the job 
just fine, certainly no worse than other languages.

>Let's see - type extensions instead of a class construct, objects
>are passive rather than active

Huh?  Your comments seem to imply that, in some other language,
objects are genuinely active.  I don't know of any mainstream
language (besides Ada) that provides such a feature in the language.

>, now we have the inability to
>inherit properties - even for capabilities defined within the
>language.  I don't know, but that OO label we're putting on 9X
>keeps getting weaker.  Oh well, the hierarchical libraries look
>pretty slick.

Please defend your comments.

-- 
type My_Disclaimer is new Standard.Disclaimer with record
	AJPO, SEI : Cognizance := Disavow_All_Knowledge;
end record;--)

Re: Extending protected types in 9X.

[Harry Koehnemann]

In article <1993Aug18.191808.24786@sei.cmu.edu> wellerd@ajpo.sei.cmu.edu (David
 Weller) writes:

>Not bloody likely.  Here's the problem: Inheriting "protection" (that
>is, inheriting properties that ensure the instance will behave in
>a concurrent environment) isn't as simple as adding a keyword
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 9x semantics it is, isn't it?  An entire operation is exclusive.
Put a P() in front and a V() at the end (OK, the readers/writers issue
might add some complexity, but it's a solved problem).  After reading
Tartan's implementor report on Protected Records, I don't see the
difficulty you're implying.  It doesn't look that bad.  Maybe
they missed something :-).

Since you have much more experience in this domain, I will take
your word that it is more complex than I make it sound.  I'd be
interested in any references you have on the subject.

>Finally,
>implementing a varied hierarchy of concurrency controls on top of
>the usual dispatching algorithms is (IMHO) something akin to a
>gordian knot made of kevlar.

This may be a rub, but I'm not sure I understand what you are saying.
What is a "varied hierarchy of concurrency controls"?  And where are
they in 9X?


>>If I need to be extensible, I'll inherit the tagged (lovely name)
>>property.  It is not enough for an OO language to inherit operations,
>>we must be able to inherit all the properties of the thing we desire
>>to become.
>
>In comparison to other common "OO" languages, Ada 9X successfully
>accomplishes this.  If you disagree, can you please elucidate?

In Eiffel, if I need to be persistent, I become persistent simply
by inheriting that property - regardles of my other properties.
Interactions are very regular and there are no "you can't protect a
tagged type" rules.  Further, they don't need to add a new construct
to the core language just to support persistent data, as Ada does
for each language feature.

Does this apply to concurrency?  I'll beat you to the punch and
admit that Eiffel does not have concurrency last I looked (it's been
a few years).  However, what precludes a "protected class" that
simply tells the compiler to protect the operations in the
interface?  Unless I'm missing something, we have P and V again.


>>Does one even "inherit" an operation in 9X - instead, it appears we
>>"gain type compatibility with" an operation.  I guess this comes
>>from the type extension approach taken in Ada9X.  We must nest
>>rather than inherit.
>
>How's that again?  My "nesting" comment wasn't related to the current
>9X type extension scheme.  I think the current scheme does the job 
>just fine, certainly no worse than other languages.

Well yes and no.  Extensions obviously give us dynamic dispatching
and let us call Ada OO - one goal of Ada9X.  Do they get in our way
with additional language capabilities?  Ada adds a unique construct
for each feature we desire.  And, those features don't play well
with one another (extending protected types).

Inheritance based languages don't have that problem.  In fact, they
can even *remove* constructs from the core language (arrays in Eiffel).
I can also combine these features through inheritance (inherit from
Persistent and Array to form Database).  I don't know how this
combining of features works in Ada9X, if at all.  Ada puts each feature
into it's own construct - constructs that won't talk to one another.
I thought I could get my combining goal by "nesting "constructs.  It
was a premature thought, and probably wrong.

I contend there is a fundamental difference between type extensions
and classes and no one has yet determined the impact on a
programming language.  Classes appear to revolve around inheritance,
while Extensions are driven by type and type compatibility- but, hey,
so is Ada.  I think the jury's still out on extensions.

--
Harry Koehnemann			Arizona State University
koehnema@enuxha.eas.asu.edu		Computer Science Department

Re: Extending protected types in 9X.

[Robert I. Eachus]

In article <1993Aug20.002552.22804@ennews.eas.asu.edu> koehnema@enuxsa.eas.asu.
edu (Harry Koehnemann) writes:

   > This may be a rub, but I'm not sure I understand what you are saying.
   > What is a "varied hierarchy of concurrency controls"?  And where are
   > they in 9X?

     To simplfy greatly you have the very low-level controls of pragma
ATOMIC, etc., the intermediate level of protected objects, and the
high level of task types.

     Full tasks can be composed, can contain other tasks, can be
components of tagged objects, can contain tagged objects, etc.
However, there is--as should be expected--a significant perfomance
penalty.

     The low-level primitives are just that, and by their nature
non-composable.

     The protected types could probably have been more composable with
other types, but their design is a tradeoff between low-level
operations and the cost of full composability.  The choice taken was
to favor performance over composibility for many reasons, but a major
factor was that you can do that with tasks if needed.

     Probably the biggest change made at the WG9 Workshop this week
was to make abstraction more orthogonal.  In fact the examples in the
resolution contained a tagged limited abstract type, and a type
derived from it.

     We do worry about such things. :-)



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Extending protected types in 9X.

[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