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-23 00:00:05 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!oleane.net!oleane!nnrp.oleane.net!not-for-mail From: "Jean-Pierre Rosen" Newsgroups: comp.lang.ada Subject: Re: Multiple entry tasks Date: Mon, 23 Apr 2001 08:55:03 +0200 Organization: Adalog Message-ID: <9c0jot$cah$1@s1.read.news.oleane.net> 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> NNTP-Posting-Host: mailhost.axlog.fr X-Trace: s1.read.news.oleane.net 988009053 12625 195.25.228.57 (23 Apr 2001 06:57:33 GMT) X-Complaints-To: abuse@oleane.net NNTP-Posting-Date: Mon, 23 Apr 2001 06:57:33 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Xref: newsfeed.google.com comp.lang.ada:6850 Date: 2001-04-23T08:55:03+02:00 List-Id: "Ted Dennison" a �crit dans le message news: jL%D6.4582> 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. Interesting. I'd rather argue that in a client-server relationship, none of the partners should trust the other one; each ensures its own security. It is true that if the client times out, it will often come back later. Mut in the meantime, it could ask on the console "Server not responding, try again?", or try a different server, or just report a failure to upper levels ("connection lost"), or.... > 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. Agreed >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. That's one use of timed entry calls. I've met other ones... > 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". There once was a famous, though unpublished paper by P. Kruchten about the "Sex of tasks", that neatly discussed "male" tasks (callers only), "female" tasks (accepters only), "hermaphrodites tasks", one special case of it being the "gender bender", etc. I don't think I have it anymore, nor that Philippe is still listening c.l.a... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr