в зависимости от того, какая реализация ожидает и работает signalAll

Я читал о reentrantlock в java и о том, как мы можем узнать условие блокировки, используя метод newCondition() в интерфейсе Condition, но затем я увидел в документация интерфейса Условие, которое пользователь должен предоставить для его использования.

Рекомендации по реализации:

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

это, как говорится, с тех пор, как пару дней я работал над проблемой обедающего философа, и мне пришлось использовать signalAll() и await() без какой-либо самостоятельной реализации!.

например, я использовал эту строку:

((Philosopher) right).getNeighborCondition().await();

где Объект right объявлен следующим образом:

Iphilosopher right= new Philosopher();

Iphilosopher — это интерфейс, а Philosopher — это класс, который его реализует и расширяет Thread.

при нажатии Ctrl + left mouse click на метод await() мне предоставляется метод интерфейса void, который выдает InterruptedException.

так какая реализация используется при вызове await() или signalAll()?!


java multithreading concurrency reentrantlock
person StudentAccount4    schedule 06.04.2020    source источник
comment
@Slaw newCondition() Возвращает новый экземпляр Condition, привязанный к этому экземпляру Lock. мой вопрос в том, где найти реализацию метода await(), а не то, что является возвращаемым значением метода newCondition() в классе lock!   -  person StudentAccount4    schedule 06.04.2020
comment
@ Слав, это немного объясняет. но не могли бы вы добавить свои комментарии в качестве ответа с некоторыми ссылками, чтобы другие могли извлечь пользу из этого вопроса и вашего ответа ?! заранее спасибо :)   -  person StudentAccount4    schedule 06.04.2020

Ответы (1)


arrow_upward
0
arrow_downward

Ваше понимание Javadoc немного неверно. Вот раздел Condition#await(), на котором вы сосредоточены:

Рекомендации по реализации

Предполагается, что текущий поток удерживает блокировку, связанную с этим Condition, при вызове этого метода. Реализация должна определить, так ли это, а если нет, то как реагировать. Как правило, возникает исключение (например, IllegalMonitorStateException), и реализация должна задокументировать этот факт.

Это говорит о трех вещах:

  1. #P4# <блочная цитата> #P5#

  2. Ответственность за определение того, удерживает ли текущий поток блокировку, лежит на реализации Condition.

  3. If the current thread does not hold the lock then what should happen is left unspecified.
    • It then goes on to say that a typical implementation will throw an IllegalMonitorStateException in such cases and that whatever approach is chosen must be documented by the implementation.

Нигде не сказано, что пользователь должен предоставить реализацию Condition#await(). Все, что в нем говорится, это то, что разработчик реализации Lock и, соответственно, Condition, должен написать код, соответствующий контракту, и предоставить необходимую документацию.

Вы упомянули ReentrantLock, который является полной реализацией Lock, поэтому давайте сосредоточимся на этом классе. Вот выдержка из документации ReentrantLock#newCondition():

  • Если эта блокировка не удерживается при вызове любого из Condition методов ожидания или сигнализации, то выдается IllegalMonitorStateException.

Это относится к пункту три выше. В этой документации указано, что возвращаемый экземпляр Condition выдает IllegalMonitorStateException, когда await() (и каждый связанный с ним метод) вызывается потоком, который не удерживает блокировку.

Но чтобы ответить на ваш вопрос напрямую: используемая реализация Condition - это любая реализация, возвращаемая Lock#newCondition(). Вы не должны заботиться о том, какой именно тип возвращается, поскольку это деталь реализации. Вот некоторые связанные понятия:

Если вы действительно хотите знать, какая реализация Condition используется, вы всегда можете посмотреть исходный код1. В настоящее время класс ReentrantLock использует экземпляры ConditionObject.

1. Предупреждение. Реализации классов java.util.concurrent.locks нетривиальны и связаны со сложностями параллелизма. Но определение используемой реализации Condition не должно быть слишком сложным.

person Slaw    schedule 06.04.2020