Re: Ada Protected Object Tutorial #1

[Robert A Duff <bobduff@world.std.com>]

kaz@ashi.footprints.net (Kaz Kylheku) writes:

> This is practical. The condition variable wait might be done inside a
> protected kernel. It would be impractical to have, say, a UNIX kernel
> call back into application code to determine if some predicate is true.

Please explain that in more detail.  I'm not sure what you're getting at
(efficiency, security, something else...).

> >in even more unnecessary context switches, and/or bugs if the
> >programmer neglects to build the evaluation of the boolean condition
> >into a loop around the condition-variable "wait" operation.
> 
> That loop around a condition variable wait is needed to resolve
> spurious wakeups and race conditions.

But the point is that with an Ada protected object, the loop is *not*
necessary -- when the task wakes up after waiting for some barrier
condition, it already owns the lock, and the condition is necessarily
True, because no other task can sneak in and modify things.

To be more precise, I should say that when an entry body is executed,
its barrier condition is True -- this execution can be done by any
task/thread, so it doesn't necessarily involve "waking up" as I said
above.  The point is that there's a piece of code depending on (say) the
fact that "this queue is empty", and when that code runs, the system
ensures that the queue is, in fact, empty -- that piece of code need not
check.

I understand why the loop is needed with Posix threads.

> I believe that providing guarantees against this sort of occurence introduces
> overhead; that is, the cure may be worse than the ailment, particularly
> on multiprocessors.

I'm not convinced.  It seems to me that repeatedly checking the same
condition is a cost, and the extra context switches (because one thread
can't check barriers on behalf of other threads) is another cost, which
Ada avoids.  Am I missing something?

- Bob