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 <r...@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.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
