* [Xenomai] [Posix skin] program test with pthread_set_mode_np @ 2013-01-22 9:41 alex alex 2013-01-22 9:56 ` Philippe Gerum 0 siblings, 1 reply; 7+ messages in thread From: alex alex @ 2013-01-22 9:41 UTC (permalink / raw) To: Xenomai 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> ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np 2013-01-22 9:41 [Xenomai] [Posix skin] program test with pthread_set_mode_np alex alex @ 2013-01-22 9:56 ` Philippe Gerum 2013-01-22 11:09 ` alex alex 0 siblings, 1 reply; 7+ messages in thread From: Philippe Gerum @ 2013-01-22 9:56 UTC (permalink / raw) To: alex alex; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np 2013-01-22 9:56 ` Philippe Gerum @ 2013-01-22 11:09 ` alex alex 2013-01-22 11:34 ` Philippe Gerum 0 siblings, 1 reply; 7+ messages in thread From: alex alex @ 2013-01-22 11:09 UTC (permalink / raw) To: Xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np 2013-01-22 11:09 ` alex alex @ 2013-01-22 11:34 ` Philippe Gerum 2013-01-22 18:30 ` Gilles Chanteperdrix 0 siblings, 1 reply; 7+ messages in thread From: Philippe Gerum @ 2013-01-22 11:34 UTC (permalink / raw) To: alex alex; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np 2013-01-22 11:34 ` Philippe Gerum @ 2013-01-22 18:30 ` Gilles Chanteperdrix 2013-01-23 10:00 ` alex alex 2013-01-23 10:16 ` Philippe Gerum 0 siblings, 2 replies; 7+ messages in thread From: Gilles Chanteperdrix @ 2013-01-22 18:30 UTC (permalink / raw) To: Philippe Gerum; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np 2013-01-22 18:30 ` Gilles Chanteperdrix @ 2013-01-23 10:00 ` alex alex 2013-01-23 10:16 ` Philippe Gerum 1 sibling, 0 replies; 7+ messages in thread From: alex alex @ 2013-01-23 10:00 UTC (permalink / raw) Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np 2013-01-22 18:30 ` Gilles Chanteperdrix 2013-01-23 10:00 ` alex alex @ 2013-01-23 10:16 ` Philippe Gerum 1 sibling, 0 replies; 7+ messages in thread From: Philippe Gerum @ 2013-01-23 10:16 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: Xenomai 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-01-23 10:16 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-01-22 9:41 [Xenomai] [Posix skin] program test with pthread_set_mode_np alex alex 2013-01-22 9:56 ` Philippe Gerum 2013-01-22 11:09 ` alex alex 2013-01-22 11:34 ` Philippe Gerum 2013-01-22 18:30 ` Gilles Chanteperdrix 2013-01-23 10:00 ` alex alex 2013-01-23 10:16 ` Philippe Gerum
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.