Concurrency management mechanisms such as wait/notify and lock/condition seem to be affected by spurious wakeups. Developers cater for those unexpected wakeups by re-checking that the condition has indeed changed.
When it comes to CountDownLatch, are spurious wakeups an issue?
The javadoc of CountDownLatch#await() states
If the current count is greater than zero then the current thread becomes disabled for thread scheduling purposes and lies dormant until one of two things happen:
- The count reaches zero due to invocations of the
countDown()method; or- Some other thread interrupts the current thread.
dormant meaning the method won't return. In other words, though a spurious wakeup can occur, it won't cause the await method to return.
You can look at the implementation to see how this is done exactly, but, in brief, it's the typical trick of looping and "waiting" (through LockSuport#park or Object#wait which are affected by spurious wakeups) until a condition is met.
When it comes to
CountDownLatch, are spurious wakeups an issue?
No.
The Object.wait/Condition.await methods are subject to "spurious wakeups".
The await method in CountDownLatch will wait until
So evenif spurious wakeup occurs, since the count has not reached,it wont return.
So the synchronizers like CountDownLatch, CyclicBarrier etc are not subject to spurious wakeups.
