имеет ли смысл Boost :: Strand производитель / потребитель?

В этот пост в блоге (2010), кто-то пытается решить проблему производителя / потребителя с помощью средства Boost :: strand. У меня такое чувство, что он упустил суть и что его программа никогда не запускает одновременно какого-то производителя и какого-то потребителя, но я не настолько опытен в библиотеке наддува, чтобы быть уверенным в этом.

  • У него есть только одна нить, на которой оба producer() а также consumer() вызовы отправляются некоторыми таймерами;
  • У него есть два потока, оба вызова io_service::run()

Тем не менее, одна нить только с гарантией того, что «ни один из этих обработчиков не будет выполняться одновременно», также означает, что мы будем или производства или же в то время как я бы сказал, что ничто не должно мешать производителю производить единицу U + t, в то время как потребитель использует единицу U, верно?

   void producer_consumer::producer() {
if ( count_ < num)   {
++count_;
intvec_.push_back(count_);
std::cout << count_ < " pushed back into integer vector." << std::endl;
timer1_.async_wait(strand_.wrap(
boost::bind(&producer_consumer::producer, this))); // loops back
timer2_.async_wait(strand_.wrap(
boost::bind(&producer_consumer::consumer, this))); // start consumer
}
}

Или я упускаю тот факт, что будут некоторые File::async_read() принятие функции strand-wrapped- «yield» в качестве обратного вызова завершения и аналогичного Socket :: ready-to-write-again, который объяснял бы, что его предложение имеет смысл до тех пор, пока действительно «продюсер ()» и «потребитель ()» части, защищенные монитором, которые взаимодействуют с общим буфером?

1

Решение

Пример кода имеет тенденцию уделять гораздо больше внимания демонстрации strand в качестве механизма синхронизации, а не предоставления решения для проблема производитель-потребитель.

Для мотивационного случая использования strand чтобы решить проблему производителя-потребителя, рассмотрим клиент чата на основе графического интерфейса, использующий TCP. Графический интерфейс может создавать несколько сообщений, пытаясь отправить сообщение до того, как предыдущее сообщение будет записано в соединение. Между тем, приложению необходимо потреблять и записывать каждое сообщение в TCP-соединение, сохраняя сообщения, что не приводит к перемежению данных. Составные операции, такие как async_write, требует, чтобы поток не выполнял никаких других операций записи, пока составная операция не завершится. Чтобы учесть это поведение:

  • Очередь может буферизировать сообщения чата.
  • GUI может опубликовать операцию в strand что будет:
    • Добавьте сообщение чата в очередь.
    • Условно запустить потребителя.
  • Потребитель — это асинхронная цепочка вызовов, которая читает из очереди и записывает в сокет внутри strand,

Увидеть этот ответ для реализации.

2

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]