Hello,
I've found a nicely "undocumented feature", in the semaphore package. I discovered
that when you initialise a semaphore with a zero count. Although everything seems to
wors fine. this means any process that do a rt_sem_wait actually wait until another
task
make a rt_sem_signal, you have a segmentation fault when you delete such a semaphore .
Even trickier, if I initialise the semaphore with a 1 value and the line after in the
code (init_module) I perform a rt_sem_wait in order to reset the count to 0, this
"new" semaphore can be deleted safely (Actually I use it as a workaround but I don't
dare show it to the QA department ;-).
I had a quick look at the rt_sem_delete function and I see that the only indirect
memory access(which is likely to trigger the segmentation fault) was the assignment
in the while loop :
(q->task)->state &= ~(SEMAPHORE | DELAYED);
I do suspect that the q->task can be a NULL pointer (after all It's initialised to 0).
The problem is that I cannot understand why the task filed could be something like a
NULL pointer
when I initialise to 0 and not a null pointer if I initialise to 1 .
I also have another side question, you can compile the scheduler using priority order
for waiting on the semaphore
or the FIFO method. My question is, if I choose the priority order and two waiting
task have the same priority, can I
assume that these two tasks will be always ordered together in a FIFO order (since
they have the same priority) ?
Thanks for helping
Laurent
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
