[Rtai] Difficulties with rt_get_state

[Paolo Mantegazza]

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.

> Besides, we also checked the status of the flags RT_TASK_READY and 
> RT_TASK_SUSPENDED, and we noticed that they can both be 1 for the same 
> task, although we expected only one of the two flags to be 1 and the 
> other to be 0.
> 
> Are we missing something ?
> 

Any task state in RTAI is kept as (RT_TASK_READY | RT_TASK_????????) always.

> Moreover, is it possible to block the mechanism of multiple suspensions ?

What do you mean, suspdep?

paolo

> 
> We kindly than you for your help,
> Laura Carnevali
> Alessandro Pinzuti
> 
> _______________________________________________
> Rtai mailing list
> Rtai at rtai.org
> https://mail.rtai.org/cgi-bin/mailman/listinfo/rtai
>