Re: Ada advocacy

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org> writes:

> That's not quite right. P can also be executing E1 or E2, in which case
> it is not "willing" to do either. T will end up at (***) in both of
> those cases as well.

I don't think you mean "P can also be executing...", you mean "some task
can also be executing...".

But anyway, no, unless I'm missing something, there are only two
possible states.  If some task is executing the body of P.E1, then P
must be locked.  So if another task comes along and tries to call one of
the entries, it will try to lock P, and will not proceed until the first
task leaves E1.  At that point, the second task will check the barrier[*],
and find it in one of the two possible states.[**]

The state "inside E1 or E2" is not an externally visible state,
so it doesn't really exist (from the clients' point of view).

In my previous message, I said that for the corresponding "passive task"
attempt to implement the same thing, the "will not accept E1 or E2"
state IS externally visible, because it could be going around the loop
back to the 'select'.  But now you've reminded me that the same thing
happens if the passive task is inside one of the 'accept' statements.

[*]That's one way to think of it, but it doesn't really matter which
task checks the barrier and executes the entry body.  In the so-called
"on behalf of" implementation model, the first task will do those things
on behalf of the second task, and then both tasks will proceed.

[**]Note that on a uniprocessor, the second task won't be running while
the first task is inside E1.  The first task's priority has been raised
to the ceiling of P, and if the second is higher than that, that's a
ceiling violation.

- Bob