Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np

[Philippe Gerum <rpm@xenomai.org>]

On 01/22/2013 12:09 PM, alex alex wrote:
> 2013/1/22 Philippe Gerum <rpm@xenomai.org>
>
>> On 01/22/2013 10:41 AM, alex alex wrote:
>>
>>> Hi,
>>>
>>> In the attached test program I test the scheduler lock operation with
>>> pthread_set_mode_np and the PTHREAD_LOCK_SCHED bit mask.
>>>
>>> Description:
>>> Two tasks are created.
>>> t1 lock the scheduler then load the cpu, sleep then load the cpu again but
>>> t2 task start when t1 sleep while the scheduler is locked. Why t1 is
>>> preempted?
>>>
>>
>> Think of what would happen would a blocked task be allowed to keep the
>> scheduler lock.
>>
>>
>>>
> According to the documentation :
> "PTHREAD_LOCK_SCHED when set, locks the scheduler, which prevents the
> current thread from being switched out by the scheduler until the scheduler
> is unlocked"
> This is what t1 do, locking the scheduler then unlocked it.
> t1 shouldn't be switched out until the scheduler be unlocked.

No. If t1 suspends willingly, then Xenomai drops the lock implicitly. 
The scheduler lock is not just yet another lock, it protects the CPU as 
a resource: this is a big massive traffic light preventing the RTOS to 
do its basic job: i.e. task scheduling.

The documentation states that no other thread will __preempt__ the 
__running__ thread holding the lock, not that a thread holding the lock 
will keep it when it decides to drop the CPU resource, in which case 
owning the lock is totally meaningless.

Functionally speaking, this situation is a gray area: there is no 
recommended behavior simply because the situation (i.e. going to sleep 
while holding the schedlock) is broken. So the RTOS has two options when 
the application does this:

- assume this behavior is a bug, don't even try to neither detect nor 
handle the situation, and let the user figure out why this is wrong (ask 
vrtx32 or VxWorks users how fun it is).

- albeit locking the scheduler without having all the resources at hand 
is generally a bad idea, assume the caller might really have a good 
reason to call a blocking service, dropping the lock while this happens, 
and reacquire it automatically when it wakes up.

#2 is current for Xenomai , because we tend to think people know what 
they are doing with a real-time API.

-- 
Philippe.