Является ли CyclicBarrier.getNumberWaiting () точным?

Question

Я анализирую код в jdk1.8, но может иметь такую ​​же проблему в другой версии jdk

1. Предположим, что party = 3 в следующем коде

   CyclicBarrier cb = новый CyclicBarrier (3);

сторон = 3 и количество> = 0,поэтому возвращаемое значение getNumberWaiting () <= 3 </strong>, но в некоторых определенных случаях более 3-х потоков будет ожидать 2.let увидит код ключа в CyclicBarrier

a) нить A в позиции 2 вернет 0, теперь есть 2 нити в позиции 3

b)после того, как поток A выполнит lock.unlock (), поток B в позиции 1 получит блокировку (но блокировка несправедлива), поэтому теперь index = 2, count = 2, он будет ожидать в позиции 3, поэтому теперь есть 3 потока ожидают в позиции 3

в) предположим, что блокировка всегда будет получена потоком из позиции 1, поэтому число ожидающих потоков будет все больше

, поэтому getNumberWaiting ()> 3 является результатом

getNumberWaiting () = (циклические числа) * party - количество

Answer 1

Я думаю, вам нужно взглянуть на концепцию "поколения" немного больше. В вашем сценарии поток А вызвал бы nextGeneration(), который сбрасывает все значения (getNumberWaiting () = 0) и сигнализирует всем текущим официантам. Те официанты (на нынешнем предыдущем поколении) скоро начнут заканчивать.

Так что да, может быть> 3 потока против условия trip, но 2 старых официанта получили сигнал об уходе, и все новые ожидают нового сигнала. getNumberWaiting не вычисляется с использованием Lock.getHoldCount(), так что все в порядке.