Age | Commit message (Collapse) | Author | Lines | |
---|---|---|---|---|
2011-09-28 | next step making barrier self-sync'd destruction safe | Rich Felker | -2/+6 | |
i think this works, but it can be simplified. (next step) | ||||
2011-09-28 | barrier destroy must also wait for threads in other processes exiting barrier | Rich 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-27 | process-shared barrier support, based on discussion with bdonlan | Rich 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-12 | initial check-in, version 0.5.0v0.5.0 | Rich Felker | -0/+6 | |