Re: Basic question about select

[Adam Beneschan <adam@irvine.com>]

On Apr 28, 5:20 pm, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> Dmitry A. Kazakov wrote:
>
> >    protected Event is
> >       procedure Signal;
> >       entry Wait;
> >    private
> >       Signaled : Boolean := False;
> >    end Event;
>
> >    protected body Event is
> >       procedure Signal is
> >       begin
> >          Signaled := True;
> >       end Signal;
> >       entry Wait when Signaled is
> >       begin
> >          Signaled := False;
> >       end;
> >    end Event;
>
> >    task PID is
> >       entry Call;
> >    end PID;
>
> >    task body PID is
> >    begin
> >       accept Call do Event.Wait; end;
> >    end PID;
>
> > begin
> >   select
> >      PID.Call;  -- Blocked in the rendezvous
> >   then abort
> >      delay 2.0;
> >      Event.Signal; -- Releases the rendezvous after 2s
> >   end select;
>
> > If abort to happen after *completion* of the rendezvous then the above
> > shall not deadlock. (I checked this under GNAT/Windows, it deadlocks
> > there.)
>
> Here the call to PID.Call is not queued, but is accepted immediately, and does
> not encounter an explicit requeue-with-abort.

Is that necessarily the case?  Since there aren't any priorities
specified, I don't think it's defined whether the body of the main
procedure (assuming it's a procedure) starts running first, or the
body of PID (assuming a single processor).  Which means that the entry
call could be queued.  Actually, on second thought, I think that for
some dispatching policies the main procedure *will* be executed first,
which means that the SELECT is executed before the body of PID starts,
which means the call *is* queued.  Of course, it will be accepted
"almost" immediately; but since the call is briefly queued, the
language of 9.7.4 means that the abortable part is started.  Then,
during "delay 2.0", PID is started, the call is accepted, but it
doesn't complete.  Then the delay finishes and the Signal occurs; an
attempt is made to cancel the entry call PID.Call, but that has no
effect since cancellation only works when the call is on a queue
(9.5.3(20)).  Anyway, as soon as the Signal occurs, the Wait
completes, then the entry call to PID.Call completes, and then
everything is done.  At least that's how I understand things, but I
could be wrong.

In any event, though, writing code like this has to be horrible since
you can't tell whether it will deadlock or not.

                             -- Adam