mutex held in a thread which is cancelled stays busy

[Erich Dollansky]

Hi,

On Tue, 6 Aug 2019 20:58:30 -0400
Daniel Eischen <deischen at freebsd.org> wrote:

> > On Aug 6, 2019, at 4:54 AM, Erich Dollansky
> > <freebsd.ed.lists at sumeritec.com> 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()?
> 
> For _trylock(), you only get EOWNERDEAD for robust mutexes.  It seems
> that you should get EOWNERDEAD for _lock() in this case, so if that's
> what you're doing, it sounds like it might be a bug.
> 
I did both. One time with initialising the mutex with its defaults by
handing over NULL as the attribute setting and one time with the
attributes set.

I use this line to set the attribute:

pres = pthread_mutexattr_setrobust (& Attr, PTHREAD_MUTEX_ROBUST);

The following line:

pthread_mutexattr_getrobust (& Attr, &pres);

Sets pres also to 1.

I am doing this on 12.0-STABLE FreeBSD 12.0-STABLE r350391 GENERIC
amd64 with the systems standard compiler.

Is this the corrent way of doing it?

Erich