mutex held in a thread which is cancelled stays busy

[Martin Simmons]

>>>>> On Wed, 7 Aug 2019 12:20:35 +0300, Konstantin Belousov said:
> DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x779KZSe066777
> 
> 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 <kostikbel at gmail.com> wrote:
> > 
> > > On Tue, Aug 06, 2019 at 08:58:30PM -0400, Daniel Eischen 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()? 
> > > 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:
> 
> If mutex is a robust mutex and the process containing the owning thread
> terminated while holding the mutex lock, a call to pthread_mutex_lock()
> shall return the error value [EOWNERDEAD]. If mutex is a robust mutex
> and the owning thread terminated while holding the mutex lock, a call to
> pthread_mutex_lock( ) may return the error value [EOWNERDEAD] even if
> the process in which the owning thread resides has not terminated.
> 
> Note the difference between shall and may.

That is clear in POSIX, so should the FreeBSD man page be changed to say
"process containing the owning thread" at least?

Currently the section starts with:

  The pthread_mutex_lock() function will fail if:

and the word "will" reads to me like a "shall", not a "may".  Code relies on
this interpretation of "will" in other man pages, e.g. for [EWOULDBLOCK] in
accept(2).

__Martin