История изменений
Исправление dvetutnev, (текущая версия) :
Он один на все потоки
Флажок это нифига не упрощение, это усложнение. В схеме с сообщением-терминатором взаимодействие продюсера/потребителя производится только через один объект - очередь. С флажком их уже становится два. Обращение к ним идет из разных потоков, возможные состояние прослеживаются сложней (создание/удаление продюсеров/потребителей/очередей, вставка/извлечение в/из очереди, взаимодействие с флажком). Многопоточка вообще тем и сложна, что число возможных комбинацией (путей выполнения) стремиться в небеса. И часть из них может оказаться некорректными. Поэтому взаимодействия из разных потоков с разделяемыми объектами нужно минимизировать. Если не последуешь совету, то вангую, что очень скоро (уже) прибежишь сюда жаловаться про странные падения из-за нарушения временной безопасности.
Объекты и их взаимодействие.
Владеет очередью потребитель (ему же обрабатывать что там накопилось), продюсер держит ссылку на очередь. До того, как продюсер отправит сообщение-терминатор, очередь всегда жива, после этого он с ней не взаимодействует. При получение потребителем сообщения-терминатора он может спокойно удалить очередь без опаски, что кто-то в нее захочет записать.
Иные говорят, что безсуловное ожидание путь к вечной блокировке.
Не место тут для таймаутов. Для бизнес логики они в дальнейшем могут потребоваться, но маскировать ими кривой дизайн путь к вечной отладке.
Исправление dvetutnev, :
Он один на все потоки
Флажок это нифига не упрощение, это усложнение. В схеме с сообщением-терминатором взаимодействие продюсера/потребителя производится только через один объект - очередь. С флажком их уже становится два. Обращение к ним идет из разных потоков, возможные состояние прослеживаются сложней (создание/удаление продюсеров/потребителей/очередей, вставка/извлечение в/из очереди, взаимодействие с флажком). Многопоточка вообще тем и сложна, что число возможных комбинацией (путей выполнения) стремиться в небеса. И часть из них может оказаться некорректными. Поэтому взаимодействия из разных потоков с разделяемыми объектами нужно минимизировать. Если не последуешь совету, то вангую, что очень скоро (уже) прибежишь сюда жаловаться про странные падения из-за нарушения временной безопасности.
Объекты и их взаимодействие.
Владеет очередью потребитель (ему же обрабатывать что там накопилось), продюсер держит ссылку на очередь. До того, как продюсер отправит сообщение-терминатор, очередь всегда жива, после этого он с ней не взаимодействует. При получение потребителем сообщения-терминатора он может спокойно удалить очередь без опаски, что кто-то в нее захочет записать.
Иные говорят, что безсуловное ожидание путь к вечной блокировке.
Не место тут для таймаутов. Для бизнес логики они в дальнейшем могут потребоваться, но маскировать ими кривой дизайн путь в вечной отладке.
Исходная версия dvetutnev, :
Он один на все потоки
Флажок это нифига не упрощение, это усложнение. В схеме с сообщением-терминатором взаимодействие продюсера/потребителя производится только через один объект - очередь. С флажком их уже становится два. Обращение к ним идет из разных потоков, возможные состояние прослеживаются сложней (создание/удаление продюсеров/потребителей/очередей, вставка/извлечение в/из очереди, взаимодействие с флажком). Многопоточка вообще тем и сложна, что число возможных комбинацией (путей выполнения) стремиться в небеса. И часть из них может оказаться некорректными. Поэтому взаимодействия из разных потоков с разделяемыми объектами нужно минимизировать. Если не последуешь совету, то вангую, что очень скоро (уже) прибежишь сюда жаловаться про странные падения из-за нарушения временной безопасности.
Объекты и их взаимодействие.
Владеет очередью потребитель (ему же обрабатывать что там накопилось), продюсер держит ссылку на очередь. До того, как продюсер отправит сообщение-терминатор, очередь всегда жива, после этого он с ней не взаимодействует. При получение потребителем сообщения-терминатора он может спокойно удалить очередь без опаски, что кто-то в нее захочет записать.
Иные говорят, что безсуловное ожидание путь к вечной блокировке.
Не место тут таймаутов. Для бизнес логики они в дальнейшем могут потребоваться, но маскировать ими кривой дизайн путь в вечной отладке.