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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8eff44ec1bcf8433 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-17 08:16:19 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!nntpserver.com!hub1.nntpserver.com!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!news-in-sanjose!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9qctpn$lil$1@news.huji.ac.il> <3BCC01B1.18C18C98@free.fr> <3BCC6CB7.20BAA30D@boeing.com> <3BCD2EC3.3B3C4498@free.fr> <3BCD91D9.C77668AA@free.fr> Subject: Re: Container reqs Message-ID: <8ghz7.32783$ev2.39537@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Wed, 17 Oct 2001 11:15:16 EDT Organization: http://www.newsranger.com Date: Wed, 17 Oct 2001 15:15:16 GMT Xref: archiver1.google.com comp.lang.ada:14816 Date: 2001-10-17T15:15:16+00:00 List-Id: In article <3BCD91D9.C77668AA@free.fr>, Jean-Marc Bourguet says... > >Ted Dennison wrote: >> >> But your "level 4" is exactly what is needed for the "gender-bender" >> server-to-server queue we were referring to. This is a *quite* common need. >> Its come up in every multitasking Ada app I've ever written of at least >> moderate complexity. Your assertion is quite wrong too. When used as I >> described, it is the *only* communication the two server tasks need. In >> fact, it is the only safe communication method they can have. > >There is a possibility I don't understand what you are refering to -- so >if you think it is the case, please explain it more thorougly. The way this has to work is that server task 1 enqueues events/info/whatever and server task 2 goes and dequeues that stuff whenever it finds some there. There clearly may be times when server task 1 is enqueing while server task 2 is dequeueing from the same queue. You can't just have them rendezvous, because you would then be using one of them as both a client and a server, which can cause real problems. In particular, you could have the hybrid client/server task blocking for long periods (not servicing requests) while the other server is busy servicing its other requests. This also makes problems with priority inversions really sticky. At best, you are needlessly slowing your system down due to unneeded client waiting. You might release a client as soon as the server receives a request, but if the server has to wait for another server, any new clients will be waiting too). If you have multiple hybrids you could even run into deadlock situations. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.