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=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 21 Aug 93 02:19:55 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Extending protected types in 9X.
Message-ID: <EACHUS.93Aug20211955@spectre.mitre.org>
List-Id: <comp.lang.ada>

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