Re: Ravenscar and context switching for Cortex-M4

[Simon Wright <simon@pushface.org>]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> AIUI, the Ravenscar rules mean that in a PO with an entry, the entry
> is basically implemented by:
> - a Boolean flag, the barrier for the entry
> - one pointer to the (at most one) task waiting on the closed entry.
>
> It would IMO not be a great complication to allow more than one entry
> per PO; it seems to enough to duplicate the above implementation
> components for each entry. Still needs no queues of tasks, as long as
> Max_Entry_Queue_Length => 1.

I think that would be OK in principle, but GNAT uses - for example - the
type System.Tasking.Protected_Object.Single_Entry.Protection_Entry, so
might get a little confused if asked to support more than one!

As for the barrier, which has to be a plain Boolean in Ravenscar (not
even "not Closed"), that's implemented using
System.Tasking.Protected_Objects.Entry_Body, which is a record
containing two accesses-to-subprogram; 'Barrier' designates a function
returning Boolean, and 'Action' implements the body of the entry. So I
think one could have more complex conditions at negligible cost.

GNAT has Profile (Restricted), see s-rident.ads; the restrictions added
to Restricted to make Ravenscar are (at 4.9.1, haven't checked whether
this has changed in 5)

   No_Calendar                      
   No_Implicit_Heap_Allocations     
   No_Local_Timing_Events           
   No_Relative_Delay                
   No_Select_Statements             
   No_Specific_Termination_Handlers 
   No_Task_Termination              
   Simple_Barriers