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.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed1.swip.net!uio.no!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed-00.mathworks.com!nntp.TheWorld.com!.POSTED!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada advocacy Date: Fri, 30 Aug 2013 18:41:33 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <19595886.4450.1332248078686.JavaMail.geo-discussion-forums@vbbfy7> <2012032020582259520-rblove@airmailnet> <12ee9bc5-3bdf-4ac0-b805-5f10b3859ff4@googlegroups.com> <6c58fae4-6c34-4d7a-ab71-e857e55897c0@x6g2000vbj.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls7.std.com 1377902493 2030 192.74.137.71 (30 Aug 2013 22:41:33 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 30 Aug 2013 22:41:33 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:WM/ekGV2erSk0hU3gZ2LllbSAMA= Xref: news.eternal-september.org comp.lang.ada:17054 Date: 2013-08-30T18:41:33-04:00 List-Id: "Jeffrey R. Carter" writes: > On 08/30/2013 09:54 AM, Robert A Duff wrote: >> "Jeffrey R. Carter" writes: >> >>> That's not quite right. P can also be executing E1 or E2, in which case >>> it is not "willing" to do either. T will end up at (***) in both of >>> those cases as well. >> >> I don't think you mean "P can also be executing...", you mean "some task >> can also be executing...". > > If we're going to use informal, active phrasing such as "P is willing" > we can also say "P is executing" without fear of misunderstanding. Fair enough. You're right -- I didn't misunderstand you. >> But anyway, no, unless I'm missing something, there are only two >> possible states. If some task is executing the body of P.E1, then P >> must be locked. So if another task comes along and tries to call one of >> the entries, it will try to lock P, and will not proceed until the first >> task leaves E1. At that point, the second task will check the barrier[*], >> and find it in one of the two possible states.[**] > > That's even worse. I don't think so. I'll try to explain why below. >...Task T is delayed waiting for the other task to > complete execution of P.E1, which can be a long time. It can be, but it should not be. Entry bodies should be kept short (at least in real-time systems, or other cases where such things matter). But in any case, it's what you want in this case -- task T must be "delayed waiting" until the other task has (quickly, we hope) set the state to one of the two possible states. We don't want it to see some oddball intermediate state. >...Those of us who > are not language lawyers (especially those who started with Ada 83) > expect a conditional entry call to send the calling task to the else > part immediately if the entry call cannot proceed. "Immediately" does not mean "in zero time". Not in Ada RM jargon, anyway. In the rendezvous case, the task doing the conditional entry call is quite likely to take LONGER (in real time) to notice that the entry is not open (than in the protected object case). And therefore longer to jump to the 'else' part. I have implemented this stuff, and I know what goes on behind the scenes -- there's (hidden) locking in the rendezvous case, too, and yes that means that it can take some time to decide to jump to the 'else'. >... (Maybe that's not > what the language rules say, but that's how it's usually presented.) > Once T sees that P is locked, it should go to the else part. That semantics doesn't seem like a good idea to me, because "P is locked" means "P is in the middle of a state change". The whole point of locking is to prevent clients from seeing that "in the middle" state. >...If the > author of T were willing to be delayed waiting to get access to P, T > would have used a timed entry call. A timed entry call with "delay 0.0" has identical semantics to a conditional entry call. In both cases (rendezvous and protected object), the calling task has to lock something before it can decide whether the call can be done "immediately", and that locking takes nonzero time. Think about the semantics of a timed call with "delay 0.000_000_000_000_000_000_001". - Bob