On 03/12/2013 10:29 AM, Petr Cervenka wrote:
>> Od: "Gilles Chanteperdrix" Komu: Petr Cervenka Datum: 11.03.2013
>> 14:05 Předmět: Re: [Xenomai] mutex problem
>>
>> CC: "Xenomai" <[email protected]> On 03/11/2013 11:35 AM, Petr
>> Cervenka wrote:
>>
>>> 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.
>>
>>
>> Could you provide us with a simple test case which would allow us
>> to reproduce the problem?
>>
>> Other than that, you can try forcing the path through the kernel
>> for every mutex call, enable the I-pipe tracer, and trigger a trace
>> as soon as you detect that the mutex is not free after a release.
>>
>
> Sadly, I'm not able to reproduce it with simple test.
That is a rather good news.
> Maybe I was not
> clear, the mutex stays not locked after "release".
The thing is, Xenomai only modifies the mutex memory during the mutex
services, so, if the problem happens between the time the mutex is
released and the time the next acquistion is done, then something else
than xenomai services changes the content of the mutex memory. There are
two possible culprits:
- your application
- the kernel-side of Xenomai.
You could try recompiling without CONFIG_XENO_FASTSYNCH and see if you
still get the issue. If you still get it, the issue definitely comes
from Xenomai kernel side.
But I think it is
> locked by something else because the seldom strange behavior. Example
> of it follows: Imagine threads A and B A acquires lock A releases
> lock B acquires lock B releases lock B tries to acquire lock, but the
> mutex is already locked and the owner is A!
>
> Also the inicialization order of threads/mutexes/... transfered the
> problem to another mutex (and threads). Owner is the same thread as
> before (hi priority, short time period).
This makes think about a memory issue. Is it possible to recompile your
application without xenomai and run it with valgrind?
>
> PS: Meanwhile I found another mutex, which was deleted immediately
> after creation, but commonly used later.
Well, yes, that could cause such issues. Could you try setting
mutex->fastlock to NULL in rt_mutex_delete?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
