Re: semantics question about SELECT statement (typos fixed)

[alex@cs.umd.edu (Alex Blakemore)]

In article <1993Mar5.145221.23827@greco-prog.fr> alabau@geocub.greco-prog.fr writes:
> Let us assume now that two requests arrive at the same time but with
> different priorities (e.g. URGENT and MEDIUM).

most methods for reasoning about concurrent processes would say they
CANNOT arrive at exactly the same time, one must preceed the other.
there are other semantic foundations, but you can reason quite successfully
about concurrent processing under the "interleaving semantics" assumption where
you must consider all possible interleavings of concurrent events.

they both could arrive before the called task was eligible to run again,
which would have a similar effect.

> The question is: WHICH ONE OF THE TWO CLIENTS WILL BE SERVICED FIRST?
> From the Reference Manual, it seems to me that the clients **in that
> case** are serviced in an arbitrary order (because the guards are not
> reevaluated). 

if they called the same entry they would be served in FIFO order by Ada83 rules.
you are correct, if they call different open entries, the language
does not define the order.

>    type LEVEL is (URGENT, MEDIUM, LOW);
>    task CONTROL is
>      entry REQUEST(LEVEL)(D :  DATA);
>    end;
    
>    task body CONTROL is
>      select
>        accept REQUEST(URGENT)(D :  DATA) do
>          ...
>        end;
>      or when REQUEST(URGENT)'COUNT = 0 =>
>        accept REQUEST(MEDIUM)(D :  DATA) do
>          ...
>        end;
>      or when REQUEST(URGENT)'COUNT = 0
>        and   REQUEST(MEDIUM)'COUNT = 0 =>
>        accept REQUEST(LOW)(D :  DATA) do
>          ...
>        end;
>      end select;
>    end CONTROL;

> It seems to me that the example below [now above] is OK only if the rendez-vous
> are serviced in the textual order.

there are even worse problems with this example.
for example, consider the case where all entry queues are empty,
task control evaluates all guards and then blocks waiting for
calls to request(low) ONLY (the other guards evaluated to false)

then even if hundreds of high and medium level requests arrive,
not a single one will be served until a low level request arrives
and is served so that the guards can be reevaluated (after the
presumably missing loop around the select stmt is executed).

this is another example of 'count getting you in trouble 
(even without timed or conditional entries)

here's a version that avoids the problem.

      select
        -- check for urgent requests
        accept REQUEST(URGENT)(D :  DATA) do
          ...
        end;
      else
        -- no urgent requests, check for medium ones
        select
          accept REQUEST(URGENT)(D :  DATA) do -- could probably remove this one
            ...
          end;
        or 
          accept REQUEST(MEDIUM)(D :  DATA) do
            ...
          end;
        else
          -- no medium ones either, handle a low request if one is waiting
          -- or the first one that arrives of any priority
          select
            accept REQUEST(URGENT)(D :  DATA) do
              ...
            end;
          or 
            accept REQUEST(MEDIUM)(D :  DATA) do
              ...
            end;
          or
            accept REQUEST(LOW)(D :  DATA) do
            ...
            end;
          end select;
        end select;
      end select;
    end CONTROL;

I believe this guarantees that at most one lower priority request
can be served before a higher one after the arrival of the
higher priority request -- for example if a low priority task is
being served at the instant a higher one arrives, it will complete its
rendezvous but no more low priority requests will be served until
the high priority queue is empty.
Presumably, this is what you want.
-- 
---------------------------------------------------
Alex Blakemore alex@cs.umd.edu   NeXT mail accepted