Re: Multiple entry tasks

[Ted Dennison<dennison@telepath.com>]

In article <9bmuo9$50h$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says...
>
>The sequence of events I was thinking of is the following:
>2) The call to Entry2 times out (it was a timed entry call).

Ahhh. I didn't think about timed entry calls. Hmmm. So you are saying that the
runtime can change the state of the entry queues between the start of a select
statement and its decision to block or immediately accept an entry? In that
case, an "abort"ed task would hose him as well, right?

Generally I find that one has to be very carful about using timed or tenative
entry calls. As a general rule, you have to be damn sure that the server will at
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. Since
I generally need to use one of those clauses, I don't use timed or tenative
rendezvous very much.

Since I usually can't use them anyway, I don't think its much of a hardship to
prohibit timed rendezvous (and aborts) for clients of this server. What you gain
by doing this is an easier to maintain structure. With the way we did it, there
are two select branches that must be maintined in lock-step for all but the
highest-priority entry. That's not a big deal with our little toy example, as
there was no code in any of the branches. But for a complicated server with
loads of code in each branch, it could be a very big deal indeed.

Then again, its possible you might want to do different things if the entry was
accepted immediately vs. waited for. In that case what we did would be better.

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