Re: [Xenomai] Corruption after phtread_mutex_destroy

[Jan Kiszka <jan.kiszka@web.de>]

Am 2015-04-23 um 20:42 schrieb Meier, Hans:
> Hi everybody,
> 
> First of all thanks a lot for your excellent work, we are using Xenomai 
> for about 8 years now in quite a complex application together with ACE 
> based on the POSIX skin and most of the time it just works fine.
> 
> But now we have a situation we think needs to be reported. 
> 
> Consider the following:
> We have a thread H with high priority, a thread L with low priority and 
> a mutex M (recursive, prio-inherit). L locks M and then H tries to lock M, 
> L gets boosted until it unlocks M, then H succeeds in locking M, then H 
> unlocks M. If H then immediately destroys and frees M, we get a corruption 
> where M's pthread_mutex_t was stored (a byte gets decremented), as soon as 
> L gets scheduled again.
> 
> According to man page PTHREAD_MUTEX_DESTROY(3P), section "Destroying 
> Mutexes" - close to the end - "Implementations are required to allow an 
> object to be destroyed and freed ... immediately after the object is 
> unlocked". So that is what we do here, we destroy and free the mutex 
> immediately after it is unlocked. Certainly in a simple scenario we could 
> easily work around this problem by destroying and freeing M later, but 
> what if this code is buried deep inside a framework lib (here ACE)? 

Not saying that ACE is to be blamed in this case (until the issue is
fully understood), but that layer is in general a rather problematic
piece of code (politely expressed).

In most projects I saw so far, it was of limited or even no real use
anymore. And it caused quite some headache due to lots of bugs,
specifically regarding concurrency, even in its "matured" parts.

So, if possible, get rid of it, at least on the long run.

Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150424/725a3be9/attachment.sig>