Neater entry point code

Neater entry point code

[Mark Rutten]

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

Re: Neater entry point code

[Matthew Heaney]

In article <34989E2A.93EF7271@dsto.defence.gov.au>, Mark Rutten
<Mark.Rutten@dsto.defence.gov.au> 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;

Note that naming the in parameter "In_Msg" isn't necessary; just use an
expanded name:

task body My_Task_Type is

   Msg : Message_Typ;

begin
...
   accept Execute (Msg : in Message_Type) do
      My_Task_Type.Msg := Msg;
   end Execute;
...

As Ben pointed out, it sounds like you want a protected object in
conjunction with a task.

You should hardly ever use T'Count for a task type, because of the race
conditions; it's pretty much a worthless attribute.

If you're ever tempted to use T'Count, don't.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Neater entry point code

[Ben Brosgol]

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

Re: Neater entry point code

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]


Mark Rutten a �crit dans le message
<34989E2A.93EF7271@dsto.defence.gov.au>...
>
>
>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.
As Ben pointed out, the 'Count attribute is not the proper way to do this,
although you can find examples of it in some very famous books about Ada
tasking... It is surprising to see how often people write this, while there
is a perfect way of checking if a rendezvous can be accepted: an else part
in a select statement. Your code should be:

    loop

      select
         accept Execute( In_Msg: in Message_Typ ) do
           Msg := In_Msg;
         end Execute;
         Add_Msg(Msg);
      else
           exit;
       end select;


    end loop;

    Execute_Stuff;