Re: [Xenomai] Corruption after phtread_mutex_destroy

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

On Fri, Apr 24, 2015 at 05:23:55PM +0200, Jan Kiszka wrote:
> On 2015-04-24 17:18, Gilles Chanteperdrix wrote:
> > On Fri, Apr 24, 2015 at 08:53:30AM +0200, Jan Kiszka wrote:
> >> 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),
> > 
> > The issue is fully understood, the mutex is considered in-use as
> > long as all threads have not exited all the mutex services. In the
> > case of the example posted, the "worker" thread is still in the
> > pthread_mutex_unlock service while the other thread is trying to
> > call pthread_mutex_destroy, which cause pthread_mutex_destroy to
> > return EINVAL.
> 
> If the reported pattern is actually equivalent to the pattern that of
> the application (wasn't clear to me so far), then it is indeed understood.
> 
> > 
> > Xenomai 3 does not have this issue.
> > 
> 
> You mean returning EINVAL instead of EBUSY?

I mean that pthread_mutex_destroy would not return an error and
destroy the mutex as it should.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150424/32e9e55f/attachment.sig>