Re: Scheduling behaviour issue

[Simon Wright <simon@pushface.org>]

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!

> Under RTEMS, if there are higher-priority tasks on that processor
> core, such actions on shared data would not have this mutual-exclusion
> property, and the shared data could be messed up. However, I'm not
> sure if such use of shared data is "correct" per the Ada RM, and if
> the resulting mess can be called "misbehaviour".

So FreeRTOS behaves in the same way as RTEMS? the RTEMS documentation
[1] says part-way through section 5.6 "All tasks with the same priority
will execute in FIFO order" (until they themselves do something to alter
this, I think; it's complicated). On the other hand, there seems to be a
variety of choices, a lot to get ones head round.

[1] https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html