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: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder02.blueworldhosting.com!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 12:54:26 -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 1377881666 31608 192.74.137.71 (30 Aug 2013 16:54:26 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 30 Aug 2013 16:54:26 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:BS0JSC3CXrKG+QLR2CTRrPzLApU= X-Original-Bytes: 3215 Xref: number.nntp.dca.giganews.com comp.lang.ada:183229 Date: 2013-08-30T12:54:26-04:00 List-Id: "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...". 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.[**] The state "inside E1 or E2" is not an externally visible state, so it doesn't really exist (from the clients' point of view). In my previous message, I said that for the corresponding "passive task" attempt to implement the same thing, the "will not accept E1 or E2" state IS externally visible, because it could be going around the loop back to the 'select'. But now you've reminded me that the same thing happens if the passive task is inside one of the 'accept' statements. [*]That's one way to think of it, but it doesn't really matter which task checks the barrier and executes the entry body. In the so-called "on behalf of" implementation model, the first task will do those things on behalf of the second task, and then both tasks will proceed. [**]Note that on a uniprocessor, the second task won't be running while the first task is inside E1. The first task's priority has been raised to the ceiling of P, and if the second is higher than that, that's a ceiling violation. - Bob