Lock-free синхронизация: как организуется нотификация между потоками?

Добрый день!

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

Задумал перевести программку на многопоточную работу. Обмен данными предполагаю делать через общий кольцевой буфер: туда периодически поступают данные, а рабочим потокам в очередь ставится задание с указанием, где в этом буфере для них лежат данные. Вопрос: как потоки должны узнать, что в очереди появилось новое задание? Задание может поступать раз в минуту, а может и 10 000 раз в секунду, какой способ уведомлений самый быстрый и ест меньше ресурсов?

Мьютексы-шмьютексы сейчас не в моде, также как и блокирующая синхронизация. Раньше сделал бы через WaitForSingleObject, но он сейчас тоже критикуется, sleep(10) - теряется оперативность реакции, PostMessage - видится самым медленным из всех. Кто как делал? Спасибо.

0

Сообщение от mss Опять же - зачем

Чтобы не дёргать QueueUserAPC лишний раз. В этом суть. Мы договорились, что число пакетов в секунду - тысячи (и плюс другим приложениям надо дать подышать). Получается тысячи вызовов QueueUserAPC против всего лишь одного.

Сообщение от mss А если нить в этот момент читает буфер

Есть способы узнать, было ли это место перезаписано с момента постановки задания до момента окончания чтения. Счётчик записанных в буфер байт, например. Если он увеличился больше, чем на размер буфера, значит данные перезаписаны.

0

Пускай рабочий поток висит на ожидании event-а. Когда event взводится в
сигнальное состояние, поток начинает в цикле забирать и обрабатывать данные
из очереди, до тех пор, пока там ничего не останется, после чего снова
уходит в ожидание.

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

Это вполне нормальная рабочая схема, которая подойдет для подавляющего
большинства сценариев такого плана. Количество рабочих потоков обычно ставят
равным количеству ядер/процессоров, хотя иногда другое соотношение может
дать лучшие результаты (зависит от специфики).

Если поток слишком часто уходит в sleep/wait, его пожно "подтюнить" с помощью
спин-ожидания, тогда прыжков в ядро и обратно будет меньше.

Если конкуренция за очередь с данными слишком высокая, ее можно распределить.
То есть, сделать несколько очередей, каждая со своей блокировкой и event-ом,
причем каждую очередь обслуживают строго определенные потоки.

Сообщение от mss APC при прочих равных условиях позволит раб.нитям максимально быстро реагировать на наличие заданий в их собственных очередях

APC, как мне кажется, заметных выгод не даст, потому что в итоге дело все
равно сведется к прыжкам туда-обратно в ядро и переключению контекстов.
Ведь для того, чтобы выполнить APC, поток должен выполнить alertable wait...

Сообщение от Postscripter Если что, речь о сетевых пакетах.

Если так, советую приглядеться к I/O Completion Ports - эта штуковина
специально заточена под такие сценарии.

1

Сообщение от Убежденный для того, чтобы выполнить APC, поток должен выполнить alertable wait

Не должен при NtAlertThread.

Сообщение от Убежденный заметных выгод не даст

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

0

Сообщение от mss Не должен при NtAlertThread.

Предлагаешь крутить в цикле NtAlertThread?

0

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

0

Сообщение от mss Готовая же поддерживаемая на уровне ОС очередь - не нужно городить огород со своими

Есть шанс, что моя очередь будет быстрее системной, если её тоже закольцевать и исключить таким образом операции выделения памяти.

Сообщение от Убежденный Доступ к очереди синхронизируется легковесно

Согласен

Сообщение от Убежденный APC, как мне кажется, заметных выгод не даст, потому что в итоге дело все равно сведется к прыжкам туда-обратно в ядро

Сообщение от Убежденный Пускай рабочий поток висит на ожидании event-а

Вот тут не понял. Ожидание event-а - это не прыжок в ядро? А установка? Event взводится через SetEvent постоянно, каждый раз по появлению новых данных? Это нормально?

_{PS системным программистам всегда завидовал)}

Добавлено через 5 минут
Установку/сброс ведь нужно оборачивать в критич. секцию? Не так здорово получается.

0

Сообщение от Postscripter Установку/сброс ведь нужно оборачивать в критич. секцию?

Установку/сброс ивента ?
Нет, не нужно.
Равно как не нужно оборачивать и любые другие API-ф-ции, работающие любыми другими глобальными объектами синхронизации.

0

а, ну да. Чёт переглючило совсем. Пойду чаю выпью.

0

Сообщение от Postscripter Вот тут не понял. Ожидание event-а - это не прыжок в ядро? А установка?

Прыжок.
Но количество этих прыжков можно минимизировать.
В данном случае рабочие потоки будут уходить в ожидание только если в
очереди для них нет данных. Поток-producer, кстати говоря, также может
"объединять" несколько вызовов SetEvent в один, если данные идут с
высокой частотой. Т.е., к примеру, на 5 порций данных достаточно 1 раз
сделать SetEvent и они все будут вычитаны рабочими потоками.

0

Так вот я и хотел проверять - если рабочий поток сейчас работает (взведён флаг "я работаю"), event не ставить. Только тогда с синхронизацией флагов заморачиваться...

В целом видение сформировалось, спасибо.

0