потому что givenLocks могло измениться, пока lock был у другого объекта.

wessen NotGonnaGetUsпотому что givenLocks могло измениться, пока lock был у другого объекта.
так ведь все синхронизированно, и почему while(...), а не If(...), ведь в любом случае проверка произойдет только один раз и потом поток либо попадет в очередь, либо получит блокировку. Ничего не понимаю...

Ну, представь.
У тебя висит 10 потоков.
В них вызывают метод getWriteLock().

9 из этих потоков заблокированны на mutex (т.к после первого вызова givenLocks=-1).

Разблокирован поток может быть только при условии, что givenLocks == 0.

Допустим не блокированный поток вызвал метод
void freeWriteLock() {
synchronized(mutex){
givenLocks = 0;
mutex.notifyAll();
}
}

После этого вызова 9 методов становяся в очередь на выполнение.
Они начнут работать друг за дружкой, как только особождается mutex.

Но!
Нам этого не нужно. Т.к. метод getWriteLock() служит для получения writeLock'.

Поэтому в первом пробуждённом потоке выставляется givenLocks = -1 и происходит выходит из блока синхронизации.

Тогда выполение переходит к следующему потоку по цепочке.
В нём делается проверка условие, поток понимает, что ему ещё спать-да-спать и вызовется метод mutex.wait().
Аналогично поступят остальные методы.
Если бы у нас было if - все бы они продолжили выполение.

Можно было бы поступить иначе: вместо mutex.notifyAll() в из freeWriteLock() вызвать метод mutex.notify() и заменить while на if. Но тогда нам пришлось бы гарантировать, что при вызове метода notify условие givenLocks !=0 всегда истинно.

Если предположить, что givenLocks отвечает за кол-во ReadLock'ов, то осуществить это будет проблемотично...

Поэтому в первом пробуждённом потоке выставляется givenLocks = -1 и происходит выход из блока синхронизации.

Затем выполение переходит к следующему потоку по цепочке.
В нём делается проверка условия, поток понимает, что ему ещё спать-да-спать и вызывает метод mutex.wait().
Аналогично поступают остальные потоки.

Если бы у нас было if, то все потоки возобновили бы свою работу.

Можно было бы поступить иначе: вместо mutex.notifyAll() в методе freeWriteLock() вызвать метод mutex.notify() и заменить while на if.
Но тогда нам пришлось бы гарантировать, что при вызове метода notify условие givenLocks !=0 всегда истинно.

Если предположить, что givenLocks отвечает за кол-во ReadLock'ов, то осуществить это было бы проблематично...

off:
сорри за русский, спать он уходит раньше, чем я :)

wessen После этого вызова 9 методов становяся в очередь на выполнение.
Они начнут работать друг за дружкой, как только особождается mutex.


А с какого места начнут выполнятся эти 9-ть потоков после вызова notifyAll, я думал, что с начала синхронизированного блока или метода, выходит, что нет, он начнет выполнятся после строки mutex.wait()? Если так, то понятно, почему while, а не if. Я прав?

Прав.