about summary refs log tree commit diff
path: root/src/thread/pthread_barrier_destroy.c
Commit message (Collapse)AuthorAgeFilesLines
* next step making barrier self-sync'd destruction safeRich Felker2011-09-281-2/+6
| | | | i think this works, but it can be simplified. (next step)
* barrier destroy must also wait for threads in other processes exiting barrierRich Felker2011-09-281-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...
* process-shared barrier support, based on discussion with bdonlanRich Felker2011-09-271-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.
* initial check-in, version 0.5.0 v0.5.0Rich Felker2011-02-121-0/+6