[Rtai] Difficulties with rt_get_state

[Paolo Mantegazza]

Marco Pantaleoni wrote:
> On Thu, Jan 21, 2010 at 2:58 PM, Paolo Mantegazza <mantegazza at aero.polimi.it
>> wrote:
> 
>> Laura Carnevali wrote:
>>
>>> Hi developers of RTAI,
>>>
>>> we have experienced some difficulties in using the RTAI primitive
>>> rt_get_state.
>>>
>>> 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.

paolo

> Ciao,
> Marco
> 
>