On Fri, Mar 18, 2016 at 09:01:00PM +0000, Kári Tristan Helgason wrote: > Ok, that makes sense. > > Can you explain why you think it's better to return EBUSY rather than > blocking on the mutex in -destroy, instead of relying on the user checking the > return code?
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. What we can't do is invent our own semantics and make pthread_barrier_destroy() wait. That's clearly not acceptable. > > > On 17 Mar 2016, at 08:05, Paul Irofti <[email protected]> wrote: > > > > On Wed, Mar 16, 2016 at 10:16:45PM +0000, Kári Tristan Helgason wrote: > >> This is very similar to the patch I had come up with for this issue. > >> > >> What is the reason for not using the local variable b in the trylock > >> in barrier_destroy()? > > > > I want that assignment to happen once we are holding the lock and we're > > sure *barrier is valid. Otherwise another thread could clear it between > > the copy and the mutex lock. >
