Re: Ada advocacy

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

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

> On 08/30/2013 09:54 AM, Robert A Duff wrote:
>> "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...".
>
> If we're going to use informal, active phrasing such as "P is willing"
> we can also say "P is executing" without fear of misunderstanding.

Fair enough.  You're right -- I didn't misunderstand you.

>> 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.[**]
>
> That's even worse.

I don't think so.  I'll try to explain why below.

>...Task T is delayed waiting for the other task to
> complete execution of P.E1, which can be a long time.

It can be, but it should not be.  Entry bodies should be kept short
(at least in real-time systems, or other cases where such things
matter).

But in any case, it's what you want in this case -- task T must be
"delayed waiting" until the other task has (quickly, we hope) set the
state to one of the two possible states.  We don't want it to see some
oddball intermediate state.

>...Those of us who
> are not language lawyers (especially those who started with Ada 83)
> expect a conditional entry call to send the calling task to the else
> part immediately if the entry call cannot proceed.

"Immediately" does not mean "in zero time".  Not in Ada RM jargon,
anyway.

In the rendezvous case, the task doing the conditional entry call is
quite likely to take LONGER (in real time) to notice that the entry is
not open (than in the protected object case).  And therefore longer to
jump to the 'else' part.  I have implemented this stuff, and I know what
goes on behind the scenes -- there's (hidden) locking in the rendezvous
case, too, and yes that means that it can take some time to decide to
jump to the 'else'.

>... (Maybe that's not
> what the language rules say, but that's how it's usually presented.)
> Once T sees that P is locked, it should go to the else part.

That semantics doesn't seem like a good idea to me, because "P is
locked" means "P is in the middle of a state change".  The whole point
of locking is to prevent clients from seeing that "in the middle" state.

>...If the
> author of T were willing to be delayed waiting to get access to P, T
> would have used a timed entry call.

A timed entry call with "delay 0.0" has identical semantics to a
conditional entry call.  In both cases (rendezvous and protected
object), the calling task has to lock something before it can decide
whether the call can be done "immediately", and that locking takes
nonzero time.

Think about the semantics of a timed call with "delay
0.000_000_000_000_000_000_001".

- Bob