From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <50FEDAB6.9070003@xenomai.org> References: <50FE6259.40406@xenomai.org> <50FE7945.2080002@xenomai.org> <50FEDAB6.9070003@xenomai.org> Date: Wed, 23 Jan 2013 11:00:59 +0100 Message-ID: From: alex alex Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Xenomai] [Posix skin] program test with pthread_set_mode_np List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Xenomai 2013/1/22 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 > >> > >>> 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.