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,d6611f5dd578d5e1,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-05-04 22:21:46 PST
Path: 
 newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!newsone.net!newsone.net!not-for-mail
From: adam@irvine.com
Newsgroups: comp.lang.ada
Subject: Protected entries requeueing themselves
Followup-To: comp.lang.ada
Date: 4 May 2001 20:31:31 GMT
Organization: NewsOne.Net - Free Usenet News via the Web - http://newsone.net/
Message-ID: <9cv3j3$h5m$1@news.netmar.com>
NNTP-Posting-Host: news.netmar.com
X-Trace: news.netmar.com 989008291 17590 205.139.138.14 (4 May 2001 20:31:31
 GMT)
X-Complaints-To: abuse@newsone.net
NNTP-Posting-Date: 4 May 2001 20:31:31 GMT
X-PNG: comp.lang.ada
X-NewsOnePostHost: larry-rp.irvine.com
X-NewsOnePostAddr: 63.206.153.98
Xref: newsfeed.google.com comp.lang.ada:7194
Date: 2001-05-04T20:31:31+00:00
List-Id: <comp.lang.ada>

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
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.

Any suggestions?  How would you implement something like this to
achieve the intended effect?  Or is my understanding of 9.5.3
incorrect? 

(P.S. This example is hypothetical.  I'm trying to understand how
requeue works; the above problem isn't one I actually have to solve.)

                                -- thanks, Adam



 -----  Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web  -----
  http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
   NewsOne.Net prohibits users from posting spam.  If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse@newsone.net