[EMAIL PROTECTED] wrote:
>
> 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 .
Usual procedure used to wake up tasks on external timers, it allows to
check overruns, but never noticed that problem. We'll look at it, thank.
> 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 .
This can be a clue.
> 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) ?
YES.
Ciao, Paolo.
-- [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/
