Re: Ada Protected Object Tutorial #1

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

On Fri, 17 Dec 1999 23:28:22 GMT, Tucker Taft <stt@averstar.com> wrote:
>Trying to provide this same capability via an "API"
>is quite awkward, as it requires the programmer to bundle up an operation and
>"submit" it along with some kind of boolean function, and allow the
>underlying run-time system decide who evaluates the boolean function
>and who executes the operation.  Almost all APIs instead are set up
>so that the programmer's code evaluates the boolean condition outside
>of the run-time system, and must do so repeatedly each time control
>returns to the user's code, to ensure that the boolean is true by
>at the moment when the user's code gets control.  This can result

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.

>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. The logic gives more ways to
the implementor to provide a correct implementation.

Suppose your thread is waiting on a condition, and the condition is signalled.
It's time to reacquire the monitor (or mutex). But a thread running on another
CPU grabs it first and changes the object so that the condition the original
thread waited for is no longer valid.

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.

>As one data point, a classic producer/consumer example with a
>bounded buffer, when coded using a protected type versus using
>mutex/condition variables, results in typically half as many
>locks and unlocks, and one third as many context switches between
>the producer and the consumer.  The mutex/condition variable
>approach involves so much more work because each thread ends up
>doing all the work "itself," rather than allowing the other thread
>to do a little bit of work on its behalf while it already holds the lock.

Is there a paper about this which argues the case in more detail?