简体   繁体   中英

Safely using CyclicBarrier.reset

In CyclicBarrier.reset javadocs, following is mentioned.

Note that resets after a breakage has occurred for other reasons can be complicated to carry out; threads need to re-synchronize in some other way, and choose one to perform the reset

Considering above hint, if I make sure barrier is not broken by using isBroken() method, is it safe to call reset() method ?

The documentation doesn't say it's unsafe to call reset() , even after the barrier is broken.

It just says it's complicated, because you need to ensure that only one thread resets it. If multiple threads reset it, then there is a chance that threads are again waiting on the barrier while the second or the third thread resets it, breaking it again (although, after breaking the barrier, it will again reset it, so it's not in an isBroken() state after that). And if only one thread calls reset, but the other threads don't wait for it, then other threads may start waiting for the barrier again before it's reset, and will get a BrokenBarrierException immediately.

Calling it when the barrier is not broken, will break the barrier for any waiting threads, and after that reset the barrier.

It's safe to call reset anytime in the sense that it doesn't create memory inconsistencies or data races inside the CyclicBarrier.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM