Query and behavior confirmation for pthread_barrier_destroy(3)

[Rich Felker]

On Thu, Sep 03, 2020 at 02:04:28PM +0200, Florian Weimer via Libc-alpha wrote:
> * Shashank Agarwal:
> 
> > Thanks for the confirmation. Please let me know if my understanding is
> > correct about pthread_barrier_destroy(3).
> >
> >> A barrier can be destroyed as soon as no threads are blocked on the
> >> barrier.
> >
> > If yes please let me know how I can verify this behaviour.
> 
> “As soon as” is imprecise; the specification predates the C/C++ memory
> model.  The caller of pthread_barrier_destroy has to establish a
> happens-before relationship with the return from the
> pthread_barrier_wait calls on the other threads.

No, return from the function is irrelevant. pthread_barrier_wait is
specified to block "until the required number of threads have called
pthread_barrier_wait()" (note "called", not "returned from calling").
As soon as the last call is made (before any of them return), the
condition ending this "block" is satisfied, and no threads remain
blocked on the barrier.

A pthread_barrier_destroy is only undefined if it "is called when any
thread is blocked on the barrier, or ... with an uninitialized
barrier". If any of the waits return, that means that no thread is
currently blocked on the barrier, so destruction is well-defined. For
example you might elect a thread to destroy the barrier immediately
based on PTHREAD_BARRIER_SERIAL_THREAD or by virtue of one having a
special role already.

In other words, barriers admit "self-synchronized destruction". Indeed
if they didn't, it would be impossible to destroy them without
coupling them with another synchronization primitive, making them
mostly useless.

> The intent with the current glibc implementation is that the
> synchronization can be achieved using the same barrier (if no thread
> blocks again on the barrier after the current round of waiting).  That
> is, in your test, thread 2 would have to wait on the barrier as well,
> unblocking both tests, and then destroy the barrier.

I don't understand what you're saying here. Do you mean that glibc
conforms but that you deem this not a conformance requirement, just an
implementation-specific property? Or something else?

Rich