Re: Delay entry selection.

[eachus@mitre-bedford.arpa (Robert I. Eachus)]

In article <2432@eonwe.gmv.es> acuenca@gmv.es (Agustin Cuenca) writes:

   Suppose the following task body;

   select 
	   accept A;
   or
	   delay 3.0;
   end select;

   Because, as I understand it, if the entry call was issued at t0+2
   seconds, the accept A shall be executed, but if it was issued at
   t0+3 seconds, the delay shall be the one selected.

   Am I missing something...

   Yes, a very subtile point about rendezvous.  A rendezvous occurs
when both tasks are ready, in the case of a call two seconds into the
delay, this occurs when the caller finally makes his call.  At this
point the rendezvous occurs with the higher of the two priorities.
Since one of these tasks (the caller) was running, the rendezvous
occurs immediately.  (It can, of course, be interrupted by a higher
priority task a nanosecond later, but the instant the rendezvous
starts is indivisible.  For you nit pickers out there, the time to
determine that a rendezvous is possible is not indivisible.)

   If the delay expires, the waiting task instantly becomes eligible
to run (whether it runs or not depends on its priority), and its entry
is no longer open for immediate rendezvous.  A caller four seconds
after the start of the delay is queued waiting for the called task to
reach another accept statement, whether or not the called task runs in
the meantime.  (Yes, it is possible to write a program to test this.
However it is the nature of such programs that they are at best
implementation dependant.)

    The rules are very deterministic.  Proving that an implementation
follows them is very tough.  :-)

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...