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: 2519 bytes --]

In article <9bpgnu$blc$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>"Ted Dennison" <dennison@telepath.com> a �crit dans le message news:
>sMGD6.3326$D4.330928@www.newsranger.com...
>> some point sit and wait for your entry. If there's an "else" or "delay"
>> clause on the server's selective wait, you can get into a nasty case of 
>> livelock.
>Timed entry calls are very useful: a client may well want to do something

I'd agree that they can occasionally be useful. However, they are tricky and
fragile.

>else if the server does not accept a request within a given time frame. You
>might well argue that in some contexts, all calls must be timed (i.e. ensure
>not infinite blocking).

I'd argue that ensuring finite blocking for clients is the *server's*
responsibility. If the client is making an entry call, then presumably it
*needs* the server to do something. So if the client is going to time out of the
call, it will probably need to come back and make the same entry call later. If
the sever *still* won't service the call, the client is really infintiely
blocking, just with a loop instead of a single block.

To prevent dead/livelocks, its really best to think of tasks in terms of clients
and servers. Tasks making entry calls are clients, and accepting tasks are
servers. In this context tenative/timed entry calls are one way to allow a
server task to *also* be a client, without neglecting its own client(s).
However, for this to work, the server task called by your hybrid client-server
task's *must* at some point block (with no time-out) on the hybrid's entry. If
the server task has a timeout in its accept, there's a possiblity that the
timeouts of the two tasks will sync up, with the result being that they will
never (or very rarely) both be ready for the rendezvous. You might be able to
arrange this properly at first, but its quite common to discover the need to add
a timeout to a server's accept statment later in debugging or maintainence, and
there's no simple way to even see that there's a client somewhere in the system
that will be hosed by this. To top it off, the fix to the client is likely going
to have to be a redesign. Yeeeeach.

Typically if you find the need for a client-server task, it is much better to
just use another task or protected object to internally queue up requests to act
as a sort of client/server "gender-bender".

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