mutex held in a thread which is cancelled stays busy
Erich Dollansky
freebsd.ed.lists at sumeritec.com
Wed Aug 7 10:26:07 UTC 2019
Hi,
On Wed, 7 Aug 2019 06:07:25 -0400
Daniel Eischen <deischen at freebsd.org> wrote:
> > On Aug 7, 2019, at 5:20 AM, Konstantin Belousov
> > <kostikbel at 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 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. 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.
Give me a bit if time and I will send you then a test program which is
extracted from my test environment. Not that the error stems from
very own test environment.
Erich
More information about the freebsd-questions
mailing list