From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,e8e240cec570cdf2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-20 12:05:02 PST Path: newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison Sender: usenet@www.newsranger.com References: <9bkevj$61k$1@nh.pace.co.uk> <9bm76r$mf6$1@s1.read.news.oleane.net> <9bmuo9$50h$1@s1.read.news.oleane.net> <9bpgnu$blc$1@s1.read.news.oleane.net> Subject: Re: Multiple entry tasks Message-ID: Date: Fri, 20 Apr 2001 19:04:47 GMT NNTP-Posting-Host: 209.208.22.130 X-Complaints-To: abuse@newsranger.com X-Trace: www.newsranger.com 987793487 209.208.22.130 (Fri, 20 Apr 2001 15:04:47 EDT) NNTP-Posting-Date: Fri, 20 Apr 2001 15:04:47 EDT Organization: http://www.newsranger.com Xref: newsfeed.google.com comp.lang.ada:6820 Date: 2001-04-20T19:04:47+00:00 List-Id: In article <9bpgnu$blc$1@s1.read.news.oleane.net>, Jean-Pierre Rosen says... > >"Ted Dennison" 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