Re: [Xenomai] SIGXCPU with rt_mutex_release

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 01/08/2013 12:12 PM, Mariusz Janiak wrote:

> Hi GIlles,
> 
> As you suggested, I have prepared simple test case that demonstrate how Xenomai is utilized by OROCOS. This test case behaves exactly the same like helloword example. Scheduler is chosen before any mutex are processed, so in my opinion it is not the case which you defined. What is really surprising is that the replacing TM_NONBLOCK with TM_INFINITE, in one before last line, do magic and suppress signal generation. Furthermore, there is no call to 'rt_task_set_mode(0, T_WARNSW, NULL);' so why 
> signal is generated? If we enable T_WARNSW in the thread, SIGXCPU is generated when mutex is locked first time in the thread. 


I guess the test could be simpler, simply:

rt_mutex_acquire
rt_task_create
rt_mutex_release
rt_mutex_acquire
rt_mutex_release

Anyway, calling rt_task_create while holding a real-time mutex is itself
a priority inversion: any thread in primary mode waiting for the mutex
will now have to wait for task running in secondary mode, so may be
block during an unbounded amount of time. So, using a real-time mutex
for this is completely useless you should be using a glibc
pthread_mutex_t. If compiling for the posix skin, use
__real_pthread_mutex_lock.

Now, how this can cause the issue you observe remains to be understood,
and probably requires a fix.

-- 
                                                                Gilles.