Igors, это ты? :)

[Old]

Класс.
Очередное одноразовое решение, которое уже завтра пойдет в корзину...
Завтра мы поняли, что нам нужно маштабировать решение и у нас теперь 10 производителей и 20 потребителей. Все перепишем?

[Авварон]

Завтра мы поняли, что нам нужно маштабировать решение и у нас теперь 10 производителей и 20 потребителей. Все перепишем?

Или не нужно будет масштабировать:)

[Old]

Или не нужно будет масштабировать:)

Но тут от подхода зависит. Можно один раз написать нормально и через какое то время просто изменить значения пары констант, а можно написать одноразово и надеятся что поток кто то перепишет нормально.

[Авварон]

Или не нужно будет масштабировать:)

Но тут от подхода зависит. Можно один раз написать нормально и через какое то время просто изменить значения пары констант, а можно написать одноразово и надеятся что поток кто то перепишет нормально.

#define нормально. С моей колокольни кажется, что вы предлагаете заниматься оверинженирингом ради premature optimisation.
Далеко не факт что именно это место будет узким местом.
Но да, какая-нибудь универсальная очередь может и решит задачу (эвентлуп с блокирующим ожиданием, наверное, решит). Но это если кто-то добрый написал эту очередь; писать её только под эту задачу с мыслью "когда-нибудь мы ее замасштабируем и переюзаем" - ну такое, похоже у вас оч много свободного времени:)

[Old]

Авварон, эта очередь пишется за 10 минут (это несколько десятков строк кода). Я сейчас с телефона, поищите тему про самодельные очереди, там это все обсуждалось. И было еще несколько тем, в одной я такую очередь выкладывал полностью. Не найдете я выложу универсальную.

[Авварон]

Авварон, эта очередь пишется за 10 минут (это несколько десятков строк кода). Я сейчас с телефона, поищите тему про самодельные очереди, там это все обсуждалось. И было еще несколько тем, в одной я такую очередь выкладывал полностью. Не найдете я выложу универсальную.

Ну, очевидно, что очередь в десяток строк кода не имеет всей полноты функционала, который можно придумать:)
Как например то, что в случае очереди событий одно событие может обрабатываться по разному разными объектами, очередь задач этого не умеет.
Чейнить задачи - тоже весьма полезная фича (чего, например, не умеют QFuture/std::future, а дустовые, вроде, умеют).

[Old]

А какой функционал там нужен, если нам нужно положить некий функциональный объект в очередь + разбудить спяших и выташить этот объект из очереди? А дальше запускай его - как он что будет обрабатывать зависит исключительно от этого функционального объекта.

[_Bers]

Никаких заморочек, знай себе открывай-закрывай семафоры, все совершенно естественно. Но увы, зная собеседников, уверен что это будет охаяно, ведь в великом std такого нет...

std::mutex? не, не слышал.
если заменить им ваш семафор, будет ровно тоже самое.

[_Bers]

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

тут какой то фейл.

"очередь событий" это и есть "очередь задач".
задача сама знает как себя исполнять.

"события" которые по разному обрабатывают разные "объекты" - не нужны.

[Авварон]

"события" которые по разному обрабатывают разные "объекты" - не нужны.

Скажите это любой гуи-библиотеке или игровому движку:)

[_Bers]

"события" которые по разному обрабатывают разные "объекты" - не нужны.

Скажите это любой гуи-библиотеке или игровому движку:)

сказал своим.
они ответили: мухи отдельно, котлеты отдельно.
событийно-управляемая модель ортогональна тред-пулу.

[Igors]

сказал своим.
они ответили: мухи отдельно, котлеты отдельно.
событийно-управляемая модель ортогональна тред-пулу.

Какой мудрый ответ! И главное - оригинальный и остроумный Про мухи и котлеты никто еще не додумался! Но вернемся к (сопливой) задачке

- сделать 2 нитки, одна принимает символ с клавы, другая печатает

Задача поставлена конкретно - 2 нитки. Чего базарить? Сказано для 2 - делайте для 2. Сказано для N - делайте для N. Разумеется это уже до задача, и заказчик обязан сформулировать внятные требования - а кто кого тогда должен печатать. А Вы обязаны снять с него за это еще бабло. Не надо лезть с решениями "на все случаи жизни" - можно (мягко) предложить -и быстренько заткнуться если нет понимания. Тише едешь - дальше будешь

Если же чисто технически - то схема семафора вполне хороша и здесь. Небольшим ее минусом обычно является то что может потребоваться еще блокировка для доступа к данным - ну это не смертельно

[Racheengel]

cv.wait(lk, []{return ready;});

Write-only code detected.

[Old]

и заказчик обязан сформулировать внятные требования - а кто кого тогда должен печатать.

Как вы ловко в воздухе переобуваетесь.
Вы же сами в большинстве своих тем рассказываете, что заказчик ничего не знает и сформулировать ничего не может. Нужно самим дорабатывать.
Не всегда заказчик с разработчиком могут оценить нагрузки. На примере интернет проектов, заказчик планировал что посещаемость сайта будет 100 человек в день, а через месяц она выросла до 10000 человек в день. Что ему делать, закрывать проект и приглашать нормальных программистов?

[Авварон]

сказал своим.
они ответили: мухи отдельно, котлеты отдельно.
событийно-управляемая модель ортогональна тред-пулу.

Не совсем, есть ряд задач, которые решаются пулом и воркерами, подписанными на бродкаст сообщений. К примеру, торговая площадка - у вас происходит сделка и надо её обработать; в каком потоке это делать - всё равно (тредпул), а вот как её обрабатывать - нет (один или несколько воркеров).