Version 1.2 of ai05s/ai05-0174-1.txt

Add a Simple_Barrier type to allow many tasks to be blocked and be released at once.

As general purpose computing is moving to parallel architectures and eventually to massively parallel machines, there is a need to effeciently schedule many (hundreds or thousands) of tasks using barrier primitives. The POSIX OS and a number of machines provide a barrier where N tasks wait on a barrier and are released simultaneously when all N are ready to execute. Functionality like this should be added to Ada.

There are many situations where the release of N tasks is required to execute an algorithm in parallel. Often the calculation is relatively small for each task on each iteration, but the number of tasks is high and the cost of linearly scheduling them and releasing them would remove almost any gains made through parallelizing them in the first place.

The simple barrier release paradigm is that N-1 tasks are blocked on a common place waiting for release. One task is executing the sequential code prior to the parallel release. When that task suspends, the release condition is satisfied and all callers can execute. One of the callers is designated as the special task, which can perform sequential actions as the other tasks queue again for their next activity.

We implement this functionality as an Ada package, a child of Ada.Synchronous_Task_Control:

When a variable of type Simple_Barrier is created with Number_Waiting = N, there are no waiting tasks and the barrier is set to block tasks. When the count reaches N, all tasks are simultaneously released and the "Last_Released" out parameter is set in [an arbitrary] one of the callers.

When the scope closing the barrier is closed, the Simple_Barrier finalization is completed after all tasks waiting on the barrier have been removed from the barrier [via abort, termination, asynchronous transfer of control]

Since it is expected that this functionality will often be mapped to hardware with a maximum number of release gates in a barrier construct, the maximum number of tasks that can be released using simple_barriers is implementation dependent. A system parameter, Maximum_Parallel_Release, provides this limit.

This paradigm was discussed at IRTAW 14, Portovenere, Italy, 7-9 October 2009. We examined alternative syntax and semantics, such as - default setting of the barrier to True or to False, - explicit releasing of the tasks via Set_True as is done in suspension objects.

We agreed that alternative functionality is needed to permit more complex interactions, but these require sharing some state and this is best done in the context of a highly optimized protected object. The extremely simple syntax and semantics provided for Simple_Barriers exactly matches the most common paradigm of N threads executing a single loop iteration and being released in a "for" loop from the loop evaluation release point. One of the threads will execute sequential parts of the program after the parallel portion is complete, but will execute its parallel portion prior to the sequential execution. The task that executes this part is determined by the return of a Boolean TRUE at the release of the barrier. It is implementation dependant whether or not the same task executes the sequential portion on different executions of a release from a single barrier.

For the case of the protected object, we agreed on the following:

** TBD **

--!corrigendum D.10.1(0)

Add an ACATS C-Test to test the new package.

****************************************************************