Fawkes API
Fawkes Development Version
|
A barrier is a synchronization tool which blocks until a given number of threads have reached the barrier. More...
#include <core/threading/barrier.h>
Public Member Functions | |
Barrier (unsigned int count) | |
Constructor. More... | |
virtual | ~Barrier () |
Destructor. More... | |
virtual void | wait () |
Wait for other threads. More... | |
unsigned int | count () |
Get number of threads this barrier will wait for. More... | |
Protected Member Functions | |
Barrier () | |
Protected Constructor. More... | |
Protected Attributes | |
unsigned int | _count |
Number of threads that are expected to wait for the barrier. More... | |
A barrier is a synchronization tool which blocks until a given number of threads have reached the barrier.
Consider you have three threads all doing work. In the end you have to merge their results. For this you need a point where all threads are finished. Of course you don't want another thread waiting and periodically checking if the other threads are finished, that will loose time - processing time and the time that passed between the threads being finished and the time when the controller checked again.
For this problem we have a barrier. You initialize the barrier with the number of threads to wait for and then wait in all threads at a specific point. After this one of the threads can merge the result (and the others may wait for another "go-on barrier".
The code in the thread would be
The threads would all get a reference to the same barriers and one would have master thread to be true.
After the barrier has been passed (count threads waited) the barrier is reset automatically and can be re-used with the same amount of barrier waiters.
The implementation of Barrier takes into account that PThread barriers are optional in POSIX. If barriers are not available they are emulated using a wait condition. Note however that on systems that do have both, barriers and wait conditions it has been observed that in a typical barrier scenario the POSIX barriers perform much better in many situations than a wait condition (processes tend to be rescheduled immediately if a barrier is reached, while with a wait condition they are rescheduled with lower priority and thus they delay may increase on a loaded system). Because of this on systems without real POSIX barriers the performance may be not as good as is expected.
fawkes::Barrier::Barrier | ( | unsigned int | count | ) |
Constructor.
count | the number of threads to wait for |
Definition at line 115 of file barrier.cpp.
|
virtual |
Destructor.
Definition at line 141 of file barrier.cpp.
|
protected |
Protected Constructor.
Does not initialize any internal structures other than setting them to 0.
Definition at line 133 of file barrier.cpp.
Referenced by fawkes::InterruptibleBarrier::InterruptibleBarrier().
unsigned int fawkes::Barrier::count | ( | ) |
Get number of threads this barrier will wait for.
Definition at line 181 of file barrier.cpp.
Referenced by fawkes::InterruptibleBarrier::InterruptibleBarrier(), FvBaseThread::release_camctrl(), and fawkes::ThreadList::wakeup_unlocked().
|
virtual |
Wait for other threads.
This method will block until as many threads have called wait as you have given count to the constructor.
Reimplemented in fawkes::InterruptibleBarrier.
Definition at line 157 of file barrier.cpp.
Referenced by fawkes::FawkesMainThread::full_start(), FvBaseThread::loop(), LaserFilterThread::loop(), fawkes::FawkesMainThread::once(), fawkes::Thread::run(), fawkes::Thread::start(), and fawkes::InterruptibleBarrier::wait().
|
protected |
Number of threads that are expected to wait for the barrier.
Definition at line 48 of file barrier.h.
Referenced by fawkes::InterruptibleBarrier::InterruptibleBarrier(), fawkes::InterruptibleBarrier::reset(), and fawkes::InterruptibleBarrier::wait().