The problem with mutexes is still present. I'm really desperate now. Does 
anyone know, how the mutex could "stay locked" when every "acquire" is sooner 
or later followed by "release" and both functions always return 0 (success) 
code?
Every advice is appreciated.

Petr

>>> 
>>>> Hello.
>>>> 
>>>> I have a problem with a mutex shared by 3 real-time user tasks.
>>>> Once in a while (~hours) the mutex get locked with the first task
>>>> as owner and the other two tasks are fronzen on rt_mutex_aquire
>>>> calls. But I have double checked, that every "acquire" of that
>>>> mutex is followed by "release".
>>>> 
>>>> Typical example: Lets call those tasks REG, SEND, RECEIVE
>>>> 
>>>> RECV: acquire RECV: release
>>>> 
>>>> RECV: acquire RECV: release
>>>> 
>>>> RECV: acquire - FREEZE
>>>> 
>>>> REG: acquire REG: release
>>>> 
>>>> REG: acquire REG: release
>>>> 
>>>> REG: acquire REG: release
>>>> 
>>>> SEND: acquire - FREEZE
>>>> 
>>>> There are also other threads, sync. objects, network sockets, ...
>>>> in the system, but the threads are frozen by this particular
>>>> mutex. rt_task_unblock call unblocks the tasks, return value of
>>>> rt_mutex_acquire is -4 (-EINTR), as expected. Used version of
>>>> Xenomai 2.5.6, skin native. Was there any known issue similar to
>>>> that behavior? Also it seems that rt_mutex_create is called
>>>> before mlockall call? Could it be a problem?
>>> 
>>> 
>>> It is a bit old to recall. Could you try and reproduce the problem
>>> with 2.6.2.1 ?
>>> 
>> 
>> I tried to use new version of everything (kernel 3.5.7, xenomai
>> 2.6.2.1, ...) and I got some exception to the kernel log in
>> rt_mutex_create. So I suppose that the problem was caused by calling
>> of rt_mutex_create before mlockall. I already fixed it and now I'm
>> waiting for some longer term results. I for now it seems to be
>> SOLVED. If not, I will let you know. Thank you for your support.
>
>
>It is not expected to get a crash, though, will try and see if I can
>reproduce the problem.
>
>-- 
>                                                                Gilles.
>

_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai

Reply via email to