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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 01/22/2013 12:34 PM, Philippe Gerum wrote:

> 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.


At some point in time Xenomai used to panic when this happened. I seem
to remember the change was made in relation to the VxWorks emulator.


-- 
                                                                Gilles.