Re: Select + Accept syntax question

["Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org>]

On 08/27/2016 12:48 PM, Andrew Shvets wrote:
> On Saturday, August 27, 2016 at 3:36:35 PM UTC-4, Jeffrey R. Carter wrote:
>>
>> So the 1st thing after "select [guard]" or "or [guard]" has to be an accept,
>> delay, or terminate statement.
> 
> I see, thank you.

Your next question, and what Holsti's was trying to get you to consider (I
think), is why it's defined this way. It's important to remember that a
selective accept can have more than 1 open accept alternative. An example of
this is given at the end of ARM 9.7.1:

24
task body Server is
   Current_Work_Item : Work_Item;
begin
   loop
      select
         accept Next_Work_Item(WI : in Work_Item) do
            Current_Work_Item := WI;
         end;
         Process_Work_Item(Current_Work_Item);
      or
         accept Shut_Down;
         exit;       -- Premature shut down requested
      or
         terminate;  -- Normal shutdown at end of scope
      end select;
   end loop;
end Server;

Now, suppose we put a Put_Line immediately prior to each accept, and that such a
statement were legal. When the task reaches the select, how does it decide which
Put_Line to execute? When does it make that decision? When does it execute the
chosen Put_Line? Remember, there may be calls waiting to either, both, or
neither of the entries.

Now, if you're going to allow one statement there, you might as well allow 2,
and if you allow 2, you might as well allow 3, and if you allow 3, you might as
well allow any sequence of statements. Such a change would make the compiler
writer's job harder, as the compiler would have to search through the statements
to find the accept (or delay) that the task should use to decide if it can
select that branch. There might be multiple accepts, for multiple entries, in
different branches of an if. While it's a general rule of language design that
ease of use should have priority over ease of compiler writing, there are limits
to how difficult it can be to write a compiler for a language. In this case, it
doesn't seem that this feature would let you do anything you can't do without
it, so the extra complexity doesn't seem justified.

Another consideration is that, if the sequence of statements is long, at some
point down the line someone might mistakenly put an accept or delay in the
sequence, creating a logic error that might be difficult to find.

Your example is not really a good use of the selective accept, as it would be
better written

accept Input ...

loop
   accept Retrieve ...
end loop;

This version is much clearer and easy to understand. It also eliminates the use
of a magic value.

Since the introduction of protected objects in Ada 95, the use of task entries
and rendezvous is less common, with many tasks communicating through POs. If
what I've written above is all your task does, it would be much better
implemented as a PO.

I presume you're trying to learn about selective accepts. A good example for
that might be the concurrent Sieve of Eratosthenes, which sets up a pipeline of
tasks, each holding a discovered prime eliminating candidates that are multiples
of its prime. After all the potential candidates have been sieved, each task in
turn should be instructed to do something interesting with its prime, such as
output it.

-- 
Jeff Carter
"Monsieur Arthur King, who has the brain of a duck, you know."
Monty Python & the Holy Grail
09