This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 3/4] nptl: Add pthread_clockjoin_np
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: libc-alpha at sourceware dot org
- Date: Mon, 14 Oct 2019 16:16:13 -0300
- Subject: Re: [PATCH v2 3/4] nptl: Add pthread_clockjoin_np
- References: <cover.3b6b26e85a044f5ad7494dfb035620d75eb57c63.1568809830.git-series.mac@mcrowe.com> <3b240188c00f3e6471d1ddeec2dfee80515da222.1568809830.git-series.mac@mcrowe.com> <d7fdba1f-86a2-0e87-24fe-12c02e9cc556@linaro.org> <20190928194532.GA31373@mcrowe.com>
On 28/09/2019 16:45, Mike Crowe wrote:
> On Thursday 26 September 2019 at 16:17:53 -0700, Adhemerval Zanella wrote:
>>> diff --git a/nptl/tst-join3.c b/nptl/tst-join3.c
>>> index a4ae459..c06e65a 100644
>>> --- a/nptl/tst-join3.c
>>> +++ b/nptl/tst-join3.c
>>> @@ -28,6 +28,8 @@
>>> #include <support/xtime.h>
>>>
>>>
>>> +#define CLOCK_USE_TIMEDJOIN (-1)
>>> +
>>> static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
>>>
>>>
>>> @@ -35,19 +37,23 @@ static void *
>>> tf (void *arg)
>>> {
>>> xpthread_mutex_lock (&lock);
>>> + xpthread_mutex_unlock (&lock);
>>>
>>
>> Maybe it would be better to move the unlock after the loop test,
>> to mimic how the other unlock does?
>
> Do you mean that I should unlock the mutex after the loop inside
> do_test_clock? If so, that would mean unlocking it on a different thread
> and that doesn't sound like it's guaranteed to be safe.
Yeah, but it is not really a strong opinion. It just make the patch
change less code in the original test.
>
> Or perhaps you meant something different?
>
> (The use of a mutex for this test works, but it's non-obvious. Perhaps a
> semaphore would be clearer?)
>
> Thanks for the rest of the review. I will make the changes you describe.
>
> Mike.
>