[Xenomai] [Posix skin] program test with pthread_set_mode_np

[Xenomai] [Posix skin] program test with pthread_set_mode_np

[alex alex]

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?

I run on Xenomai 2.6.2 with linux kernel 3.2.21.

Thanks in advance.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-pthread_set_mode_np.bz
Type: application/octet-stream
Size: 1302 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130122/97ba44e9/attachment.obj>

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

[Philippe Gerum]

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.

>
> I run on Xenomai 2.6.2 with linux kernel 3.2.21.
>
> Thanks in advance.
>
> Alex
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: test-pthread_set_mode_np.bz
> Type: application/octet-stream
> Size: 1302 bytes
> Desc: not available
> URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130122/97ba44e9/attachment.obj>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
Philippe.

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

[alex alex]

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.

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

[Philippe Gerum]

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.

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

[Gilles Chanteperdrix]

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.

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

[alex alex]

2013/1/22 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.
>
Indeed my example is not very relevant..., the sleep would be in the task that
does not use the lock. Anyway, my problem was not about the pthread_set_mode_np
function but about the linking configuration with the xeno-config
scriptwhich doesn't
return the correct ldflags.

Thank you fo your well developed answer.
Regars.
Alex.

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

[Philippe Gerum]

On 01/22/2013 07:30 PM, Gilles Chanteperdrix wrote:
> 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.
>
>

Yes, to deal with the issue of managing taskLock() from userland while 
keeping migration to secondary mode safe, since we have to suspend the 
caller on the relax condition. This qualified as a good reason to 
provide a temporary lock break for the schedlock.

-- 
Philippe.