> Well, lets start at the beginning. The program you showed isn't > correctly using barrier_destroy according to the latest Posix standard: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_barrier_destroy.html > >> The results are undefined if pthread_barrier_destroy() is called when >> any thread is blocked on the barrier, or if this function is called with >> an uninitialized barrier. > > They removed the EBUSY requirement and made it optional. We try to keep > that behavior because it's a sensible thing to do that costs little to > implement.
The spec is pretty light on details in this case, and I feel the spec can be interpreted in a way that makes use such as that in my program very natural. >> What we can't do is invent our own semantics and make >> pthread_barrier_destroy() wait. That's clearly not acceptable. > > And yet, that's what everyone does. I've looked at several implementations and they all seem to take this approach. Fact of the matter is, I think most programmers treat these primitive pthread functions as if the operations within them happen atomically (out of sight, out of mind) and I think that the least surprising behaviour is to have _destroy block until all threads have left _wait, as that is probably what the programmer intended anyway.
