Я очень хорошо знаком с тем, как схема сигнализации wait()/notify()
работает на Java. Однако я понял, что несколько моделей использования, которые я видел, являются вариантами схемы Продюсер/Потребитель или реализация Барьера. Также я видел реализации некоторых известных параллельных проблем, таких как обеденные философы, использующие wait/notify, но, видимо, для дидактических целей.
Более того, все схемы следовали хорошо зарекомендовавшей себя рекомендации всегда вызывать wait()
внутри цикла и только изменяют некоторую общую переменную после прохождения цикла, как и следующий код:
synchronized(mon) {
// #CP1 - Do not change variables here
while !(mycondition) {
try{
// #CP2 Do not change variables here
mon.wait();
} catch(catch (InterruptedException e) { e.printStackTrace(); }
}
// Condition satisfied - Now you can change!
makeOperation();
// Tell others that you're done and exit
mon.notifyAll();
}
Мои вопросы: есть ли другие способы использования сигнализации wait()/notify()
чем те, которые я привел? Вы когда-нибудь использовали его неправославным способом? Зачем? Вот еще несколько конкретных вопросов, которые помогут:
#CP1
и #CP2
?notify()
вместо notifyAll()
? Хотя возможное усиление производительности, когда вы очень уверены в этом, не вызовет какой-то мертвой блокировки? Зачем?mycondition
зависит от более чем одного потока, например mycondition= a_ready && b_ready && c_ready
?
wait
иnotify
является нестандартным способом управления потоками. Можно утверждать, что с ними ничего нельзя сделать, чего нельзя сделать с помощью инструментовjava.util.concurrent
и без краевых эффектов.wait
иnotify
являются стандартными, так какjava.util.concurrent
. Но есть ли кто-то использующийjava.util.concurrent.locks.Condition
, который является своего рода высокоуровневой заменой дляwait/notify
? Если это так, вопрос все еще остается в силе.