Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Aug 2019 14:38:55 +1000
From:      MJ <mafsys1234@gmail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: mutex held in a thread which is cancelled stays busy
Message-ID:  <d1877cab-5d39-b384-53fa-dc5087419388@gmail.com>
In-Reply-To: <f8a3c53b-179b-57fd-51ce-d72d5e0d7956@gmail.com>
References:  <20190806165429.14bc4052.freebsd.ed.lists@sumeritec.com> <1FC05CEB-982F-484F-9E41-5A74FF564494@freebsd.org> <20190807095521.23e79874.freebsd.ed.lists@sumeritec.com> <f8a3c53b-179b-57fd-51ce-d72d5e0d7956@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Sorry scratch that, I got confused. Doing 3 things at once.

On 7/08/2019 2:32 pm, MJ wrote:
> I just noticed this:
> 
> pthread_mutexattr_getrobust (& Attr, &pres);
> 
> Why are you passing &pres? It should be the address of 
> PTHREAD_MUTEX_ROBUST (or  PTHREAD_MUTEX_STALLED ?)
> I would expect you should get EINVAL when testing the above statement.
> 
> 
> The Freebsd manual says:
> "If successful, these functions return 0."
> Refer: PTHREAD_MUTEXATTR(3)
> 
> 
> 
> On 7/08/2019 11:55 am, Erich Dollansky wrote:
>> Hi,
>>
>> On Tue, 6 Aug 2019 20:58:30 -0400
>> Daniel Eischen <deischen@freebsd.org> 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()?
>>>
>>> For _trylock(), you only get EOWNERDEAD for robust mutexes.  It seems
>>> that you should get EOWNERDEAD for _lock() in this case, so if that's
>>> what you're doing, it sounds like it might be a bug.
>>>
>> I did both. One time with initialising the mutex with its defaults by
>> handing over NULL as the attribute setting and one time with the
>> attributes set.
>>
>> I use this line to set the attribute:
>>
>> pres = pthread_mutexattr_setrobust (& Attr, PTHREAD_MUTEX_ROBUST);
>>
>> The following line:
>>
>> pthread_mutexattr_getrobust (& Attr, &pres);
>>
>> Sets pres also to 1.
>>
>> I am doing this on 12.0-STABLE FreeBSD 12.0-STABLE r350391 GENERIC
>> amd64 with the systems standard compiler.
>>
>> Is this the corrent way of doing it?
>>
>> Erich
>> _______________________________________________
>> freebsd-questions@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to 
>> "freebsd-questions-unsubscribe@freebsd.org"
>>
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to 
> "freebsd-questions-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d1877cab-5d39-b384-53fa-dc5087419388>