[Rtai] Difficulties with rt_get_state
mantegazza at aero.polimi.it
Thu Jan 21 18:00:15 CET 2010
Marco Pantaleoni wrote:
> On Thu, Jan 21, 2010 at 2:58 PM, Paolo Mantegazza <mantegazza at aero.polimi.it
>> Laura Carnevali wrote:
>>> Hi developers of RTAI,
>>> we have experienced some difficulties in using the RTAI primitive
>>> We implemented a kernel module with four tasks that share two binary
>>> semaphores: task1 and task4 share mux1, task2 and task3 share mux2.
>>> We call rt_get_state in order to check the status of the flag
>>> RT_SCHED_SEMAPHORE, which is supposed to be 1 when the task is blocked on a
>>> semaphore. According to this, we expect the flag RT_SCHED_SEMAPHORE to be 1
>>> either for task1 or for task4, and, in a similar manner, we expect it to be
>>> 1 either for task2 or task3. However, during the execution, sometimes the
>>> flag turns out to be 1 for all the four tasks.
>> So? That function is a simple single liner info: return task->state;.
>> Are you so sure there is no instant in which all of the task can be in
>> ready state? That is an info function and nothing should be taken for
>> granted on the returned state. In fact at the very instant you can look at
>> it maybe has changed already, even more than once.
> just guessing, but could it be wise to check its value between a cli/sti
> pair? I guess that not all the tasks should be blocked on the same
> semaphore, except in case of a bug in the client code.
She does not point to any mulfunction, maybe SMP is in the game.
More information about the Rtai