Re: [Xenomai] Issue in __threadobj_unlock_sched (forge/mercury)

[Matthias Schneider <ma30002000@yahoo.de>]

----- Original Message -----

> From: Philippe Gerum <rpm@xenomai.org>
> To: Matthias Schneider <ma30002000@yahoo.de>; "xenomai@xenomai.org" <xenomai@xenomai.org>
> Cc: 
> Sent: Friday, May 2, 2014 10:27 AM
> Subject: Re: [Xenomai] Issue in __threadobj_unlock_sched (forge/mercury)
> 
> On 05/01/2014 04:23 PM, Matthias Schneider wrote:
> 
>>  b) threadobj_lock_sched() saves prio and policy and sets it to
>>  SCHED_RT/threadobj_lock_prio
> 
> Forcing SCHED_RT in threadobj_lock() is the core issue. Doing so allows 
> SCHED_OTHER callers to hold that lock: does it make sense? Maybe it's 
> handy so that client code does not have to care, on the other hand, this 
> very much sounds like introducing priority inversion by design.
> 
> What would be the use case for holding the sched lock over SCHED_OTHER?
> 
> 
> -- 
> Philippe.
> 

There are some points I would like to raise about this issue:

a) the policy active before holding the "scheduler lock" is actually reapplied, 
but the threadobj info about this is left inconsistent
b) independent from wether SCHED_OTHER is a use case, SCHED_RR and SCHED_RT/SCHED_FIFO 
definitely are.
c) In my recently published FreeRTOS prototype, the "main" thread calling 
TaskSchedulerStart is actually a SCHED_OTHER thread that takes the scheduler 
lock

Nevertheless, please have a look at the code again, it seems like a simple bug 
to me.

Consider the following:

current task is SCHED_RR, prio 5

threadobj_lock_sched()
 -> SCHED_RT, prio 99

threadobj_unlock_sched()
 -> SCHED_RR, prio 5

threadobj_lock_sched()
 -> SCHED_RT, prio 99

threadobj_unlock_sched()
 -> SCHED_RT(!), prio 5

Regards,
Matthias