Re: multiple delay alternative

[Robert Eachus <rieachus@comcast.net>]

On Sunday, March 4, 2018 at 11:08:25 PM UTC-5, Bojan Bozovic wrote:

> Delay will simply stop execution (not schedule the task) for an amount of time until the condition needed is met, and then process the task entry.

This is one of those confusing statements of reality that looks like it says something special.  If the delay expires and all processors are running higher priority tasks, the delayed entry call continues to wait, but now for reasons of priority.

When trying to understand what is going on, you can normally divide the tasks in a program into those that make entry calls, and those that accept entry calls.  (Yes, task initialization may do the opposite to start up a set of worker tasks.)  Now:

> If you have both delayed and non-delayed entries for the same "accept" in "select" non-delayed will be executed (as far as I can tell)...

>   select 
>    entry_call_alternative 
>   or 
>    delay_alternative 
>   end select;

From the calling side, this is the only delay alternative.  It says to wait on the entry for N seconds, then give up if the entry is not available in that time.

Tasks that are waiting to be called can have multiple accept statements available--this is the selective accept.  Looks similar, but it is on the accepting side.  Notice that one of the most common uses of the selective accept is to have a terminate alternative.  This results in an orderly shutdown of all waiting tasks.  Yes, if you don't need orderly, or need an emergency shutdown you can use an abort statement.

The important thing to remember is that tasks come in these two flavors, callers and servers.  There is an important subset of server tasks which always runs (once created) in the calling task's thread of control.  These have mostly been replaced by protected objects.

Oh, and sometimes you have worker tasks, which call an entry to get a work unit, eat up a chunk of CPU time, call an entry to deliver results then go back to the original entry call.  There are several ways to shut these down, but I haven't found a (non-ugly) version that uses a terminate alternative. (Aborting the whole group of worker tasks when all the work is done is often the most practical.)