Expand description
A synchronization barrier that adapts to the number of subscribing threads.
This has the same goal as the std::sync::Barrier, but it handles runtime additions
or removals of thread subscriptions ‒ the number of threads waiting for the barrier can change
(even while some threads are already waiting).
It can be convenient if your algorithm changes the number of working threads during lifetime. You don’t need a different barrier for different phases of the algorithm.
But most importantly, the Barrier is robust in face of panics.
§Problems with panics and the std::sync::Barrier
If we have a barrier that was set up for n threads, some of the threads park on it and wait
for the rest to finish, but one of the other threads has a bug and panics, the already parked
threads will never get a chance to continue and the whole algorithm deadlocks. This is usually
worse than propagating the panic and cleaning up the whole algorithm or even shutting down the
whole application, because then something can recover by restarting it. If the application
deadlocks in the computation phase, but otherwise looks healthy, it will never recover.
This makes applications less robust and makes tests which use barriers very annoying and fragile to write.
Our Barrier watches the number of subscribed threads (by counting the number of its own
clones, unlike the standard barrier, this one can and need to be cloned for each thread). If a
thread disappears (or is added), the expectations are adjusted.
It also has a mode in which it’ll get poisoned and propagate the panic to the rest of the group.
Structs§
- A Barrier to synchronize multiple threads.
- A result after waiting.
Enums§
- What to do if a
Barrieris destroyed during a panic.