I analysis the code in jdk1.8, but may have same issue in other jdk version
Let's assume the parties = 3 in the following code
CyclicBarrier cb = new CyclicBarrier(3);
parties = 3 and count > = 0, so the return value of getNumberWaiting() <= 3 but in some certain cases, more than 3 threads will be waiting 2.let's see the key code in CyclicBarrier
a) thread A in position 2 will return 0, now there are 2 threads await in position 3
b) after thread A execute lock.unlock(), thread B in position 1 get the lock(but the lock is unfair), so now index = 2, count =2, it will await in position 3, so now there are 3 threads await in position 3
c) let's assume, the lock will always be got by the thread from position 1, so the number of waiting thread will be more and more
so the getNumberWaiting() > 3 is the result
getNumberWaiting() = (cyclic numbers) * parties - count
I think you need to look at the "generation" concept a little more. In your scenario, Thread A will have called nextGeneration()
which resets all counts (getNumberWaiting() = 0) and signals all current waiters. Those waiters (on the now-previous generation) will shortly start completing.
So yes, there may be >3 threads against the trip
Condition but 2 x old waiters have been signalled to leave and any new ones are awaiting a new signal. The getNumberWaiting
is not computed using Lock.getHoldCount()
so this is OK.
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.