1:
Объект Condition связан (и получен из) объекта Lock (он же mutext). Javadoc для класса довольно ясно относительно его использования и применения. Чтобы дождаться выполнения условия, вы должны получить блокировку, и это хорошая практика кодирования, чтобы делать это в блоке try / finally (как у вас). Как только поток, получивший блокировку, ожидает условия для этой блокировки, блокировка освобождается (атомарно).
Q2:
Использование таймерного ожидания необходимо для обеспечения жизнеспособности вашей программы в случае, если условие, которого вы ждете, никогда не наступит. Это определенно более сложная форма, и она совершенно бесполезна, если вы не проверяете факт истечения времени ожидания и не принимаете меры для обработки условия истечения времени ожидания.
Использование сна является приемлемой формой ожидания чего-то происходящего, но если вы уже используете Lock ("mutex") и имеете переменную условия для этой блокировки, не имеет смысла не использовать время метод ожидания условия :
Например, в вашем коде вы просто ожидаете определенный период, но НЕ проверяете, произошло ли условие или истекло время ожидания. (Это ошибка.) Вам следует проверить, вернул ли ваш синхронизированный вызов значение true или false. (Если он возвращает false, то истекло время ожидания, и условие НЕ произошло (пока)).
public void myThreadA(){
mutexA.acquire();
try{
while(runningA){ //runningA is a boolean variable
if(conditionA.await (sleepATimeoutNanos))
commonActivity();
else {
// timeout! anything sensible to do in that case? Put it here ...
}
}
}
finally{
mutexA.release();
}
}
Q3: [отредактировано]
Фрагменты кода требуют более подробного контекста, чтобы быть понятными. Например, не совсем понятно, все ли условия в потоках одинаковы (но я предполагаю, что они есть).
Если все, что вы пытаетесь сделать, это убедиться, что commonActivity () выполняется только одним потоком за раз, AND, некоторые разделы commonActivity () НЕ требуют контроля за конкуренцией, AND, вам требуется, чтобы средство истекло в ожидании вы можете просто использовать семафор . Обратите внимание, что у sempahore есть свой собственный набор методов для временных ожиданий .
Если ВСЕ из commonActivity () критически важны, и AND, вы действительно не против ожидания (без тайм-аутов) просто сделайте commonActivity () синхронизированным методом.
[окончательное редактирование :)]
Чтобы быть более формальным, условия обычно используются в сценариях, когда у вас есть два или более потоков, взаимодействующих в задаче, и вам требуется передача обслуживания между потоками.
Например, у вас есть сервер, который обрабатывает асинхронные ответы на запросы пользователей, и пользователь ожидает выполнения объекта Future. Состояние в этом случае идеальное. Будущая реализация ожидает условия, и сервер сообщает о его завершении.
В старые времена мы использовали wait () и notify (), но это был не очень надежный (или тривиально безопасный) механизм. Объекты Lock и Condition были разработаны именно для устранения этих недостатков.
(A хороший онлайн-ресурс в качестве отправной точки )
Купите и прочитайте эту книгу .