bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: race condition destroying condition variables


From: Brent W. Baccala
Subject: Re: race condition destroying condition variables
Date: Wed, 27 Dec 2017 15:07:51 -0500

On Wed, Dec 27, 2017 at 2:31 PM, Samuel Thibault <samuel.thibault@gnu.org> wrote:
Hello,

Brent W. Baccala, on mar. 26 déc. 2017 23:06:13 -0500, wrote:
> Also, the Linux source code in nptl/ includes the following comment:
>
>   /* If there are waiters which have been already signalled or
>      broadcasted, but still are using the pthread_cond_t structure,
>      pthread_cond_destroy needs to wait for them.  */

Ok, so even if Posix explicitly says that it has undefined behavior,
since nptl behaves fine we should probably behave fine too.

Let me clarify - that comment precedes a block of code in pthread_cond_destroy() that waits for the other threads.

See glibc-2.23/nptl/pthread_cond_destroy.c, around line 50.

That code's been rewritten in glibc-2.25, but the requirement is still there.

glibc-2.25/nptl/pthread_cond_destroy.c, lines 38-40:

Thus, we can assume that all waiters that are still accessing the condvar have been woken.  We wait until they have confirmed to have woken up by decrementing __wrefs.

... and then it waits for "wrefs >> 3" to become zero.

My point was that since Linux waits for the other threads in pthread_cond_destroy(), we should too. 

    agape
    brent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]