Re: Ada Protected Object Tutorial #1

[kaz@ashi.footprints.net (Kaz Kylheku)]

On Sun, 26 Dec 1999 19:20:04 GMT, Robert Dewar <robert_dewar@my-deja.com> 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.
>
>Why? Because protected objects in Ada have relatively nasty low
>level semantics that do not compose properly, because of the

That's the sense that I get. For example, earlier in the debate I was told that
when the requirements change in certain ways, you have to abandon protected
objects. E.g. if you need an object's operation to call into another subsystem
which may call back.

I buy the argument that it's often better to do with fewer threads.  When
software has to synchronize with itself internally via a rendezvous mechanism,
that is a waste of time. It's more efficient to just let threads go loose into
foreign objects and do as much work as possible in a non-blocking manner.
Using send/receive/reply discipline for synchronization is a waste of cycles.
Though it can lead to software that is easier to debug, no contest there.