mutex held in a thread which is cancelled stays busy
Daniel Eischen
deischen at freebsd.org
Wed Aug 7 17:26:34 UTC 2019
> On Aug 7, 2019, at 6:25 AM, Erich Dollansky <freebsd.ed.lists at sumeritec.com> wrote:
>
> 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.
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
More information about the freebsd-threads
mailing list