Эффективная и прозрачная синхронизация для кода реального времени

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

Типовая схема такова:

• Имеется один или несколько управляющих потоков, запускающих или останавливающих асинхронную (выполняемую по внешним или таймерным событиям) обработку данных - например, обмен со внешним устройством, сетью, какие-нибудь длительные вычисления/преобразования и т.п.
• Имеется один или несколько потоков реального времени, реализующих эту асинхронную обработку.
• Управляющие потоки могут ожидать на блокирующих средствах синхронизации, но потоки реального времени крайне желательно избавить от любых блокировок и вызванных ими ожиданий, а также инверсии приоритетов.
• При запуске/остановки асинхронной обработки управляющие потоки должны корректно синхронизироваться и с потоками реального времени, и между собой, чтобы исключить гонки и взаимоблокировки.

Один из типичных примеров взаимодействия:

• Один из управляющих потоков обнаруживает (пришло сообщение, юзер нажал кнопку и т.п.), что нужно запустить асинхронную обработку. Для этого нужно вначале выделить определенные ресурсы (состояние подготовки), что может потребовать ожидания, и в этот период возможны гонки с другими управляющими процессами (например, юзер успел передумать и нажал кнопку отмены). После успешной подготовки нужно дать потокам реального времени (которые все это время могут обрабатывать другие данные) отмашку, что можно начинать работать и по "новому заказу" (состояние работы).
• Соответственно, любой из управляющих потоков в любой момент может обнаружить, что асинхронную обработку нужно остановить, для чего нужно дать сигнал о завершении обработки и перейти в состояние "запрос остановки", затем подождать, пока завершится текущий проход асинхронной обработки (если он есть), а если нет - обеспечить корректный переход к состоянию "остановка завершена", и при этом исключить гонки с другими управляющими потоками, которые могут попытаться как остановить асинхронную обработку, так и запустить ее.

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

Может, кто встречал толковые ресурсы по такой тематике, или имеет собственные проверенные наработки?

0

Некоторое время назад столкнулся с похожей проблемой: необходимо было в приложении
обрабатывать сообщения от пользователя, от системы, создавать и уничтожать рабочие
потоки, а еще приостанавливать и возобновлять их работу, при этом сами потоки также
должны были взаимодействовать с основными компонентами и уведомлять их, например, о
завершении своей работы... Синхронизация сразу стала больным вопросом, потому что
при таком количестве компонентов и их взаимосвязей легко нарваться на круговые
зависимости и получить дедлок.

В поисках решений пришел к выводу, что такие схемы лучше всего реализовывать на основе
оконных сообщений. Т.е. создается некий manager со скрытым или message-only окном и
отдельным потоком, который крутит цикл выборки оконных сообщений. Все команды
поступают в этот manager в виде стандартных оконных сообщений. Оконные сообщения,
как известно, обрабатываются синхронно, строго в порядке очереди. Соответственно,
никаких других средств синхронизации может вообще не потребоваться.

Правда, здесь требуется соблюдать определенную иерархию блокировок. Например, manager
может ждать завершения команд от потоков или завершения самих потоков, но потоки не должны
ждать manager-а. Т.е. они могут делать PostMessage (постановка сообщения в очередь), но
не должны SendMessage, иначе снова получится круговая зависимость и дедлок.

Вместо очереди сообщений можно использовать какой-нибудь самописный механизм, не суть.
Главное - это централизованное, а не разбросанное по 50 местам, управление и синхронизация.

0

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

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

У меня есть одно древнее приложение, которое крутит передачу звука по MME, как раз через оконные сообщения MM_WIM_DATA/MM_WOM_DONE. Если поставить размер порции в районе 10-15 мс, то на медленных процессорах начинает заикаться, если просто быстро подергать над окном мышью, а если включить анимацию сворачивания/разворачивания окна и покликать туда-сюда, то заикается даже на быстрых.

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

0