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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7ef40c364905158c
X-Google-Attributes: gid103376,public
From: Ben Brosgol <brosgol@world.std.com>
Subject: Re: Neater entry point code
Date: 1997/12/18
Message-ID: <3498AF47.7B75@world.std.com>#1/1
X-Deja-AN: 299246055
Content-Transfer-Encoding: 7bit
Sender: news@world.std.com (Mr Usenet Himself)
References: <34989E2A.93EF7271@dsto.defence.gov.au>
Mime-Version: 1.0
Reply-To: brosgol@aonix.com
Content-Type: text/plain; charset=us-ascii
Organization: Aonix
Newsgroups: comp.lang.ada
Date: 1997-12-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Mark Rutten wrote:
> 
> The code that I have at the moment looks like
> 
>     while Execute'Count /= 0 loop
> 
>       accept Execute( In_Msg: in Message_Typ ) do
>         Msg := In_Msg;
>       end Execute;
> 
>       Add_Msg(Msg);
> 
>     end loop;
> 
>     Execute_Stuff;
> 
> What I'm trying to do is extract anything that's queued up
> on the entry point and then go off and do something else.
> 
> Is there a neater way of doing this? I don't want to use another
> task to do either Add_Msg or Execute_Stuff.
> 
> Thanks,
> Mark

This code has a couple of race conditions. 

(1) Just after Execute'Count evaluates to 0, a call may arrive, but it
will not be accepted.  Presumably either the program doesn't care if it
misses such calls, or else some other part of the code will accept it
later (or perhaps the entire fragment shown is in an outer loop).

(2) Potentially more seriously, assume that there is a call pending on
Execute, and thus Execute'Count /=0 evaluates to True, but before
control reaches the accept statement the calling task either times out
or is aborted.  Then the task containing the code fragment will be
blocked at the accept, and it will not be able to proceed until another
call arrives. 

(3) A call of Execute that arrives while another one is being accepted
will be served by a later iteration of the loop; I assume that was
intended.  

Whether there is a "neater way" to solve the problem depends on whether
these race conditions are a concern.  If you need to solve (2) then you
will probably want to reformulate the program using a protected object
(with a protected entry for Execute), and a signaling task calling a
protected procedure to indicate that it is time to service the callers.  

Ben Brosgol
brosgol@aonix.com