Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | next step making barrier self-sync'd destruction safe | Rich Felker | 2011-09-28 | 1 | -2/+6 |
| | | | | i think this works, but it can be simplified. (next step) | ||||
* | barrier destroy must also wait for threads in other processes exiting barrier | Rich Felker | 2011-09-28 | 1 | -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 bdonlan | Rich Felker | 2011-09-27 | 1 | -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.0 | Rich Felker | 2011-02-12 | 1 | -0/+6 |