Re: Multiple entry tasks

[Ted Dennison<dennison@telepath.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

In article <9bm76r$mf6$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>
>"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> a �crit dans
>le message news: 9bkevj$61k$1@nh.pace.co.uk...
>> select
>>     when (Entry2'Count <= 0) and (Entry1'Count <= 0) =>
>>         accept Entry3 ;
>>     when (Entry1'Count <= 0) =>
>>         accept Entry2 ;
>> or
>>     accept Entry1;
>> else
>>     terminate;
>> end select ;
>>
>This is wrong. Guards are evaluated only when the select is entered (unlike
>POs), therefore if a task cancels its call (through timed entry call) while
>the guards are being evaluated, you may end up in a situation of infinite
>blocking.

:-)

I made the same misreading as you on my first post. The guards will only close
if there is already an entry available on another branch. In that case the
higher priority entry will be immediately accepted, so there will be no blocking
at all. Thus there cannot be infinte blocking (execpt where intended :-) ).

I think the confusing part was that he used "<= 0" rather than "= 0". 'count
logically shouldn't ever go negative, but I guess he was trying to be safe
(perhaps there's some degenerate case about that in the LRM. I'd check it if
this were production code I was writing). I'd only expected to see a
two-character boolean of ">= 0", so that's what my brain reported. :-(

>select
>   accept Entry1;
>else
>   select
>      accept Entry2;
>   else
>      select
>         accept Entry1;
>      or
>         accept Entry2;
>      or
>         accept Entry3;
>      or
>         terminate;
>      end select;
>   end select;
>end select;
>
>1) Show that the sequence above exhibits a race condition
>2) Show that the race condition is perfectly acceptable.

Marin's code has the same "race condition". I also touched on that in a previous
post, but I'm always happy to go into more detail. :-)

Its quite possible for this server task to find no entries available and block
down in the inner select (or in Marin's case, block with all the guards open).
At that point, its quite possible for two separate tasks to become ready and
enqueue on Entry1 and Entry2 before this server task becomes active again. At
that point, the selection of which entry to accept will be based on factors
other than the priority we have tried to set up. However, I would consider such
"simultanious entries" to be a degenerate case which is really no worse than the
case where the server task accepts Entry_3 8 CPU cycles before a client requests
Entry_1. The duration of the inversion is practicly the same, and in both cases
Entry_1 is still properly queued, and will take priority over any other Entry_2s
and Entry_3s that arrive afterwards.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com