Re: mutex held in a thread which is cancelled stays busy

Hi,

On Wed, 7 Aug 2019 12:20:35 +0300
Konstantin Belousov <[email protected]> wrote:

> On Wed, Aug 07, 2019 at 04:37:57PM +0800, Erich Dollansky wrote:
> > Hi,
> > 
> > On Wed, 7 Aug 2019 10:10:02 +0300
> > Konstantin Belousov <[email protected]> wrote:
> >   
> > > On Tue, Aug 06, 2019 at 08:58:30PM -0400, Daniel Eischen wrote:  
> > > >     
> > > > > On Aug 6, 2019, at 4:54 AM, Erich Dollansky
> > > > > <[email protected]> wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > for testing purpose, I did the following.
> > > > > 
> > > > > Start a thread, initialise a mutex in a global variable, lock
> > > > > the mutex and wait in that thread.
> > > > > 
> > > > > Wait in the main program until above's thread waits and
> > > > > cancel it.
> > > > > 
> > > > > Clean up behind the cancelled thread but leave intentional the
> > > > > mutex locked.
> > > > > 
> > > > > I would have expected now to get an error like 'EOWNERDEAD'
> > > > > doing operations with that mutex. But I get 'EBUSY' as the
> > > > > error.    
> > > > 
> > > > Are you initializing the mutex as a robust mutex, via
> > > > pthread_mutexattr_setrobust()?  Are you using _lock() or
> > > > _trylock()?   
> > > Robust mutexes only have special properties on the process
> > > termination. They behave same as the normal mutexes if the owning
> > > thread is terminated.
> > >   
> > man says:
> > 
> >  [EOWNERDEAD]  The argument mutex points to a robust mutex and the
> >  previous owning thread terminated while holding the mutex lock.  
> 
> So what ?  It describes the case when error can be returned, but it is
> not required to do so.  POSIX wording is the following:
> 
what does POSIX matter when the manual of the operating system the
program is running on states something else?

Erich
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[email protected]"