Re: Ada Protected Object Tutorial #1

[Robert Dewar <dewar@gnat.com>]

In article <slrn85om2b.dog.kaz@ashi.FootPrints.net>,
  kaz@ashi.footprints.net wrote:
> The protected types as described are utterly useless to me
> because of the limitations of what they can do. I can't think
> of any software I have written in the past two years in which
> protected types could have been applied (had I been working in
> Ada). In almost everything I have done, there are complex
> relationship among the collaborating objects. There are calls
> among the objects from within critical regions, as well as
> condition waits in arbitrary places.

You have not quite got the idea yet :-)

For such complex collaborating objects, we use tasks in Ada.
Indeed everything that can be done with a protected object
can be done with a task, it is just that tasks require more
apparatus and hence have higher overhead.

Protected objects are typically used to provide low level
data oriented synchronization primitives. For example it is
straightforward to construct a classical semaphore using a
protected type, or (and this is the important point) any
other similar synchronization mechanism, customized to the
needs of your application.

> Non sequitur. I was talking about the cost of implementing
> specific semantics, such as atomically passing ownership of a
> locked object to a specific thread so that the thread doesn't
> have to re-evaluate a predicate.

But keeping track of ownership is pretty critical for the
purposes of implementing priority inheritance. One of the
important features of Ada is that much of the programmer's
job in avoiding priority inversion is automatic.

There was incidentally no wishy-washy in the response, you
just missed the underlying point :-)

> The fact is, if you have a thread running on another processor
> that is about to seize a lock, and you have to suspend that
> thread because the current owner is passing ownership of the
> lock to some specific thread, that is a waste of processor
> time.

It is never a waste of processor time to be careful about
priority inversions. The world is scattered with examples of
real time applications that have been written ferociously
carefully to minimize task switching etc, but because of
priority inversion fall on their faces. As always choosing
the correct algorithms is more important, and implementing
incorrect or dangerous algorithms efficiently is not a good
substitute!

You are really operating from an insufficient knowledge of
Ada here. I would recommend reading the Burns and Welling
book on real time programming (this is not entirely Ada
specific, but it does give a good view of how common real
time paradigms are implemented in Ada). See www.adapower.com
for a full reference.

> I'd like to hear from somone who has experience with these
> so-called protected types on a machine with 16 processors or
> more. What is the scalability like of existing
> implementations?

Our SGI customers use protected types routinely in SGI
multi-processor machines, and they work just fine. Again,
your problem is that you have the wrong view of protected
types. They are low level gizmos that simply provide basic
access to simple locking operations from which other primitives
can be constructed.

For example, if you want a little array that multiple processors
need to read and write with appropriate protection, then at the
OS level, you need a lock and you need to set and free the lock
appropriately, and you need to worry about priority inversion
effects that could happen if you don't worry about them (e.g.
from a high priority task preempting a low priority task that
owns the lock).

All this would be automated with a simple protected type in
Ada, including worrying about inversion (that's achieved by the
use of ceiling priority protocol, which is of course a super
efficient method on a single processor, and still probably the
best approach on a multi-processor, but you do need an OS level
lock in this case).

There is certainly nothing magic in Ada, but what Ada gives you
is

a) A semantic abstraction level that is one step above the
direct posix primitives, resulting in safer, easier to maintain
code. This abstraction is achieved without introducing any
significant inefficiency.

b) Full portability. Even fully standards compliant posix
implementations vary in ways that can compromise protability.
For example, if you raise your priority, and then lower it,
can you lose control to an equal priority task? Answer for
POSIX is may be -- implementation dependent. Answer for Ada
is no.


Robert Dewar
Ada Core Technologies

P.S. since this goes to comp.programming.threads, it is perhaps
appropriate to remind people that complete production quality
Ada 95 compilers for all common targets are freely available.
Go to the FTP directory pub/gnat at cs.nyu.edu for details.
There you will find public releases of the GNAT technology.
These are intended for student and research use, and are just
the thing for familiarizing yourself with the advantages that
Ada can bring to threads oriented programming.

Corresponding fully supported commercial versions of GNAT
Professional are available from Ada Core Technologies
(sales@gnat.com).


Sent via Deja.com http://www.deja.com/
Before you buy.