Re: mutex held in a thread which is cancelled stays busy
Daniel Eischen <[email protected]>
| Newsgroups | gmane.os.freebsd.questions,gmane.os.freebsd.devel.threading |
|---|---|
| Message-ID | <[email protected]> |
> On Aug 7, 2019, at 6:25 AM, Erich Dollansky <[email protected]> wrote: > > Hi, > > On Wed, 7 Aug 2019 06:07:25 -0400 > Daniel Eischen <[email protected]> wrote: > >>> On Aug 7, 2019, at 5:20 AM, Konstantin Belousov >>> <[email protected]> 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 <[email protected]> wrote: >>>> >>>>>>> On Tue, Aug 06, 2019 at 08:58:30PM -0400, Daniel Eischen wrote: >>>>>>> >>>>>>> On Aug 6, 2019, at 4:54 AM, Erich Dollansky >>>>>>> <[email protected]> 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. -- DE _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[email protected]"