Date: Wed, 7 Aug 2019 12:20:35 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Erich Dollansky <freebsd.ed.lists@sumeritec.com> Cc: Daniel Eischen <deischen@freebsd.org>, freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mutex held in a thread which is cancelled stays busy Message-ID: <20190807092035.GG2731@kib.kiev.ua> In-Reply-To: <20190807163757.2b5d52fa.freebsd.ed.lists@sumeritec.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190807092035.GG2731>