Re: Ada Protected Object Tutorial #1

[Laurent Guerby <guerby@acm.org>]

kaz@ashi.footprints.net (Kaz Kylheku) writes:
> >This claim is wrong, when you're inside a protected procedure, calls
> >to other protected procedure on the same object are done
> >without locking of course.
> 
> This requires the procedures to be passed information about whether
> the object is locked by this thread or not. For example, a hidden
> parameterr.

No, the Ada compiler can statically make the difference between an
internal and external call. There is no locking involved at all for
internal calls. That is the fundamental point of protected procedures,
they are lightweight and efficient, but you are of course restricted
on what you do inside them.  If you need to do more things, you use an
entry, and then there are locks and all the stuff you mention.

> Another thing that is possible is that the compiler might generate
> two function images: one that assumes the lock and one that does
> not.  When a protected procedure calls another one for the same
> object, the compiler will generate a call to the variant which does
> not acquire the lock.

That is exactly what GNAT does (and I assume other Ada compilers do
the same).

> These solution requires some measure of clairvoyance: what if the
> protected procedure calls into another subsystem which then calls
> back into a protected procedure on the same object? How do you pass
> the ``already_locked'' knowledge across calls to foreign subsystems?

There is no clairvoyance involved, it is just that the Ada language is
designed to allow an efficient implementation of protected
procedures. The language defines as a bounded error when potentially
blocking operation is called from a protected procedure, or when
jumping around brings you back to the original protected object.

See RM 9.5.1 for details.

--LG