Date: Wed, 7 Aug 2019 06:07:25 -0400 From: Daniel Eischen <deischen@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Erich Dollansky <freebsd.ed.lists@sumeritec.com>, freebsd-questions@freebsd.org, freebsd-threads@freebsd.org Subject: Re: mutex held in a thread which is cancelled stays busy Message-ID: <AFA42FF8-C49F-495F-BD4A-F9FBB9301F5E@freebsd.org> In-Reply-To: <20190807092035.GG2731@kib.kiev.ua> 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>
index | next in thread | previous in thread | raw e-mail
> 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()? -- DEhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFA42FF8-C49F-495F-BD4A-F9FBB9301F5E>