Re: mutex held in a thread which is cancelled stays busy

> 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()?

--
DE
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "[email protected]"