Date: Thu, 8 Aug 2019 14:09:45 +0800 From: Erich Dollansky <freebsd.ed.lists@sumeritec.com> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mutex held in a thread which is cancelled stays busy Message-ID: <20190808140945.7eb235aa.freebsd.ed.lists@sumeritec.com> In-Reply-To: <BC58A1D4-C77A-49F4-B6D6-F85A8C13832E@freebsd.org> References: <20190806165429.14bc4052.freebsd.ed.lists@sumeritec.com> <1FC05CEB-982F-484F-9E41-5A74FF564494@freebsd.org> <20190807071002.GF2731@kib.kiev.ua> <20190807163757.2b5d52fa.freebsd.ed.lists@sumeritec.com> <20190807092035.GG2731@kib.kiev.ua> <AFA42FF8-C49F-495F-BD4A-F9FBB9301F5E@freebsd.org> <20190807182548.1a8e00dd.freebsd.ed.lists@sumeritec.com> <BC58A1D4-C77A-49F4-B6D6-F85A8C13832E@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
On Wed, 7 Aug 2019 13:26:31 -0400
Daniel Eischen <deischen@freebsd.org> wrote:
> > On Aug 7, 2019, at 6:25 AM, Erich Dollansky
> > <freebsd.ed.lists@sumeritec.com> wrote:
> >
> > Hi,
> >
> > On Wed, 7 Aug 2019 06:07:25 -0400
> > Daniel Eischen <deischen@freebsd.org> wrote:
> >
> >>> On Aug 7, 2019, at 5:20 AM, Konstantin Belousov
> >>> <kostikbel@gmail.com> 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 <kostikbel@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@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. We only process robust
> >>> list on the process termination. If the process is still alive,
> >>> but the thread terminated, it can only happen because the process
> >>> code asked for the thread termination explicitly, and then the
> >>> code should be able to keep its own state. On really fatal
> >>> conditions, like unhandled signals, kernel terminates the
> >>> process, not a thread.
> >>
> >> But pthread_mutex_lock() should not return EBUSY; that is only for
> >> _trylock(). It seems to me _lock() should either return EOWNERDEAD
> >> or EDEADLK, or it just blocks indefinitely.
> >>
> >> Erich, are you getting EBUSY for pthread_mutex_lock() or is that
> >> only for pthread_mutex_trylock()?
> >>
> > EBUSY is only returned when I call 'pthread_mutex_trylock'. The
> > other one just hangs.
>
> In this case, I think FreeBSD is behaving correctly. I think perhaps
> the only problem is that the man page isn't reflecting the POSIX
> wording.
>
it is not so clear. This is also the reason why I finally relied on the
FreeBSD man page. It says at the bottom:
The pthread_mutex_lock() function conforms to ISO/IEC 9945-1:1996
("POSIX.1").
Which is pretty old.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html
The Open Group Base Specifications Issue 7, 2018 edition
IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)
...
When you check that document out, it becomes even more confusing as it
says in one case 'thread' and in the other case 'process'. This makes
it a bit confusing for programmers as especially the unlock function
should be only called by the thread holding the lock.
How this was defined by the FreeBSD manuals made it very clear to
programmers..
To come back to your comment. So, even when we assume the Open Group
has the final say, pthread_mutex_unlock is wrong as it shall
release the mutex when held by a dead thread but it does not.
The whole thing looks to me that the author of the man page used some
logic which did not make it into the software.
Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190808140945.7eb235aa.freebsd.ed.lists>