summaryrefslogtreecommitdiff
path: root/src/thread/pthread_barrier_destroy.c
AgeCommit message (Collapse)AuthorLines
2011-09-28next step making barrier self-sync'd destruction safeRich Felker-2/+6
i think this works, but it can be simplified. (next step)
2011-09-28barrier destroy must also wait for threads in other processes exiting barrierRich Felker-0/+2
the vm lock only waits for threads in the same process exiting. actually this fix is not enough, but it's a start...
2011-09-27process-shared barrier support, based on discussion with bdonlanRich Felker-0/+6
this implementation is rather heavy-weight, but it's the first solution i've found that's actually correct. all waiters actually wait twice at the barrier so that they can synchronize exit, and they hold a "vm lock" that prevents changes to virtual memory mappings (and blocks pthread_barrier_destroy) until all waiters are finished inspecting the barrier. thus, it is safe for any thread to destroy and/or unmap the barrier's memory as soon as pthread_barrier_wait returns, without further synchronization.
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker-0/+6