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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f15aeba9975c472f X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-10-01 12:26:10 PST Path: archiver1.google.com!news2.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!kibo.news.demon.net!news.demon.co.uk!demon!diphi.demon.co.uk!jpt From: JP Thornley Newsgroups: comp.lang.ada Subject: Re: Protected Entry Call Semantics Date: Wed, 1 Oct 2003 20:22:28 +0100 Message-ID: References: NNTP-Posting-Host: diphi.demon.co.uk Mime-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Trace: news.demon.co.uk 1065036369 23135 80.177.171.182 (1 Oct 2003 19:26:09 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 1 Oct 2003 19:26:09 +0000 (UTC) User-Agent: Turnpike/6.02-S () Xref: archiver1.google.com comp.lang.ada:79 Date: 2003-10-01T20:22:28+01:00 List-Id: In article , Stephan Heinemann writes >Hi, > >regarding entry calls on protected objects that cannot be immediately >selected, i.e., they are closed, the ARM states the following in C.9.5.3 >(13,15): > >-- >When a queued call is selected, it is removed from its entry queue. >Selecting a queued call from a particular entry queue is called servicing >the entry queue. An entry with queued calls can be serviced under the >following circumstances: > >[...] > >If after performing, as part of a protected action on the associated >protected object, an operation on the object other than a call on a >protected function, the entry is checked and found to be open. >-- > >Well, my problem is the "can be serviced" in C.9.5.3 (13). I am using >the Ravenscar profile and there may be only one task waiting on a >protected entry. Other tasks trigger that waiting task by opening the >associated barrier. Lets say there is one such triggering task that >accesses the protected object twice during its response >(just for example, the same could be done with two tasks, each >triggering once). The first access opens the barrier while the second >one closes it. > >Now, some implementations may choose to let the triggering task >execute the protected action of the waiting task and position the >latter after the entry call for its resumption. For other >implementations, the waiting task executes its protected action itself >and therefore it depends on the scheduler whether the waiting task >may enter the protected object or not , i.e., if a time slice is given >to it or not. For the example given, this would be between the two >triggering tasks. > (I replied earlier from my work address but it doesn't seem to have made it out, apologies if this is a repeat.) I don't think that there is any problem here. During the completion of the first protected action of the triggering task all the entry queues are serviced (9.5.1(7)), so the waiting task will get past the barrier at this point. So the fact that the barrier may become closed later isn't going to stop it executing. (If I have understood your question correctly.) Cheers, Phil -- JP Thornley