Re: Ada Protected Object Tutorial #1

[Tucker Taft <stt@averstar.com>]

Robert Dewar wrote:
> 
> In article
> <Pine.A41.3.96-heb-2.07.991226141254.25330A-100000@pluto.mscc.hu
> ji.ac.il>,
> > This very interesting article tries to explain why it
> > is almost always better to use protected types, and create
> > less tasks. It gives detailed examples of many tasking idiom,
> > so it is also helpful as a guide to Ada tasking.
> 
> I disagree with this conclusion. Indeed my view is that it is
> almost always better to use an intermediate task than a
> protected object unless you specifically need the low level
> efficiency that protected objects can provide in some
> implementations...

One of the critical features of protected objects is the
guarantee of bounded priority inversion.  In non-real-time
systems, this is generally irrelevant.  In real-time systems,
it can be essential to achieving schedulability.  So
it is not so much "low level efficiency" as "bounded
priority inversion" that protected objects provide,
which is a somewhat higher level concern
in real-time systems.

Perhaps there should be two separate variants of protected types,
one that bounds priority inversion, and imposes other restrictions,
and one that has no particular restrictions, but makes no
guarantees.  This would clearly need to be a "spec" property of the
protected type, so which variant is wanted would need to be
identified somehow in the protected type specification.

Historically, we were trying to create a feature to address
real-time concerns with rendezvous.  The fact that the protected
type construct has since been recognized as a potentially useful
paradigm for non-real-time synchronization is nice, but may
require some liberalization of the language rules
to ensure this kind of use is portable across implementations.

-Tucker Taft  stt@averstar.com
AverStar, Inc.   Burlington, MA  01803