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=-2.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, MAILING_LIST_MULTI,PP_MIME_FAKE_ASCII_TEXT autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,d6611f5dd578d5e1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-05-08 12:38:07 PST Path: newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!193.251.151.101!opentransit.net!jussieu.fr!enst!enst.fr!not-for-mail From: Wilhelm.Spickermann@t-online.de (Wilhelm Spickermann) Newsgroups: comp.lang.ada Subject: RE: Protected entries requeueing themselves Date: Tue, 08 May 2001 21:35:57 +0200 (CEST) Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-Trace: avanie.enst.fr 989350686 48535 137.194.161.2 (8 May 2001 19:38:06 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Tue, 8 May 2001 19:38:06 +0000 (UTC) To: comp.lang.ada@ada.eu.org Return-Path: X-Mailer: XFMail 1.4.0 on Linux X-Priority: 3 (Normal) In-Reply-To: <9cv3j3$h5m$1@news.netmar.com> X-Sender: 0211750756-0001@t-dialin.net Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.3 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: newsfeed.google.com comp.lang.ada:7336 Date: 2001-05-08T21:35:57+02:00 On 04-May-01 adam@irvine.com wrote: > My second question about protected objects and requeueing: > > 9.5.2(31) says that although you can't use a formal parameter in an > entry barrier, but need to look at the parameters before deciding If the parameter to be put into the entry barrier has just a few different values, a family entry would solve the problem. The family parameter may be used in the barrier. > whether to handle it, "the entry_barrier can be 'when True' and the > caller can be requeued (on some private entry) when its parameters > indicate that it cannot be handled immediately." > > Although this makes sense intuitively, I'm having trouble figuring out > how it would work in a seemingly simple case. Suppose I have a > protected object that looks like this: > > protected PR is > entry E1 (Min_Count : in integer; Result : out integer); > procedure PROC1; > private > Count : integer := 0; > end PR; > > Suppose PROC1 increments Count. The intent of E1 is for each calling > task to wait until Count has been incremented past whichever point > that task desires. This is illegal: > > entry E1 (Min_Count : in integer; Result : out integer) > when Min_Count >= Count is ... > > Intuitively, it seems like this should work: > > entry E1 (Min_Count : in integer; Result : out integer) when True is > begin > if Min_Count < Count then > requeue E1; > end if; > Result := ... > > with the intended effect being that after PROC1 is called, all the > entries on E1 will be executed to check their Min_Count, and those > that don't meet the requirement will requeue themselves, while those > that do will complete. > > But I don't think it works. As I read 9.5.3, it seems that when E1 > requeues itself, the protected action continues, and this includes > servicing entry queues, and since "servicing of entry queues continues > until there are no open entries with queued calls" (9.5.3(18)), but > this entry will always be open and there will always be a queued call > on it, since the task keeps requeueing itself on the entry. Thus, the > result of this is an infinite loop. > > I recognize that 9.5.2(31) suggests using a private entry, but I'm not > sure how. If the barrier on the private entry is "when True", the > same problem occurs; but I can't think what other barrier could be put > on the private entry to make things work. You could copy the attribute COUNT of the private entry to a variable "How_Many_To_Go" of the protected type in PROC1 and use "How_Many_To_Go>0" as the barrier of the private entry; it�s body should decrement the variable. But using the COUNT attribute is like walking on thin ice. (Think about aborts and timed entry calls.) _And_ You will need a "Pragma Queuing_Policy (FIFO_Queuing)" I like it more to use two private entries which requeue to each other and open alternating -- switching occurs every time PROC1 is called. As both of them have the same code and switching reduces to setting a variable, a family of two entries is handy. You can also use "requeue with abort" here without running into problems. (I hope someone will intervene, if I�m telling wrong or misleading things.) Wilhelm