Re: Ravenscar and context switching for Cortex-M4

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 15-02-13 14:41 , G.B. wrote:
> On 12.02.15 22:28, Niklas Holsti wrote:
>> On 15-02-12 22:25 , Patrick Noffke wrote:
>
>>> According to
>>> http://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gnathie_ug/the_predefined_profiles.html#ada-restrictions-in-the-ravenscar-profiles,
>>>
>>>
>>> at most one task may be queued on an entry.  I take this to mean *on
>>> a single entry* and that two tasks may be simultaneously queued on
>>> separate entries.  Is that correct?
>>
>> Definitely correct.
>
> Are you sure this is correct?

Yes, as I understood the question.

> The profile includes
>
>                     Simple_Barriers,
>                     Max_Entry_Queue_Length => 1,
>                     Max_Protected_Entries => 1,
>                     Max_Task_Entries => 0,

So?

> I thought "essentially no queuing" (hence no more than one
> simple entry per object) is a good rule of thumb for Ravenscar
> profile based programming.

Ravenscar allows at most one entry per protected object; that is what 
Max_Protected_Entries => 1 means. It is a fixed limitation, not a rule 
of thumb.

Two or more tasks can be simultaneously queued (i.e. blocked) on 
separate entries, as long as no more than one task is queued on any 
given entry. These separate entries must be in as many separate 
protected objects, because each PO can have at most one entry.

However, the number of entries per PO is not the essential factor for 
queuing. In some more permissive tasking profile, there could be 
multiple entries per PO, and there would still be no queues of blocked 
tasks if the constraint Max_Entry_Queue_Length => 1 is retained.

The OP said:

 > I have two POs, each with an interrupt handler and an entry.
 > [snip]
 > Then I have two tasks, T1 and T2.  T1 is blocked on
 > PO1's entry and T2 is blocked on PO2's entry.

Entirely within Ravenscar rules, and the very pattern for handling two 
different interrupts in a Ravenscar application.

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.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .