Re: Scheduling behaviour issue

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

On 2020-04-23 13:56, Simon Wright wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 
>> I'm not sure about the definition of a "correct [Ada] application" in
>> this context, but it seems to me that the Ada RM rule means that if
>> several tasks have the same priority, they can assume mutual
>> non-pre-emption, in essence that the running task will not yield to
>> another task within this same-priority set until the running task
>> explicitly blocks or yields.
>>
>> Under that rule, therefore, tasks at the same priority, on the same
>> processor core, can act on shared data without mutual-exclusion
>> protections -- more or less as in a co-operative, non-pre-emptive
>> system -- even if they are pre-empted by higher-priority tasks (which
>> do not share these same data). The tasks in the same-priority set just
>> have to take care not to block or yield while engaged in such actions
>> on shared data.
> 
> I see what you mean. Seems like a fragile design under possible priority
> reassignment. Not obvious why the work couldn't be done in a single task
> - no problem!

There are various logical reasons why one may want to divide different 
SW functions into different tasks -- say, the tasks are triggered 
sporadically by different input signals but contain several internal 
suspension points embedded within their respective algorithms. A 
possible reason to give two different tasks the same priority is that 
the system supports only a handful of priorities, and luckily there is 
no reason (from real-time requirements) to assign different priorities 
to these two tasks, so that distinct priority levels can be saved for 
other tasks.

As I said in a later post, I agree that using static priority 
assignments to ensure synchronization or mutual exclusion between tasks 
is fragile, and more robust methods (protected objects) are preferable.

On the other hand, I often see posts on e.g. comp.arch.embedded from 
people who prefer co-operative multi-tasking (or even single-thread 
programming). They could find it attractive to use such designs based on 
this Ada feature.

Several coding standards (rulebooks) or design standards that I've seen 
have rules forbidding tasks of equal priority, I assume in order to 
avoid uncertainties about execution order, including the case under 
discussion.

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