Совместно используемая память POSIX - метод автоматического уведомления клиента c

Question

Я исследую общую память POSIX для IP C вместо очереди сообщений POSIX. Я планирую сделать область разделяемой памяти достаточно большой, чтобы вместить 50 сообщений по 750 байт каждое. Сообщения будут отправляться через произвольные интервалы от нескольких ядер (серверов) одному ядру (клиенту), который получает сообщения и предпринимает действия на основе содержимого сообщения.

У меня есть три вопроса о разделяемой памяти POSIX:

(1) есть ли способ автоматического уведомления клиента c о появлении новых данных, например, методы, доступные для каналов POSIX и сообщений очереди?

(2) Какие проблемы могут возникнуть при использовании разделяемой памяти без блокировки, когда данные являются однократными или однократными?

(3) Я прочитал, что разделяемая память - это самый быстрый метод IP C, поскольку он имеет самую высокую пропускную способность, и данные сразу становятся доступными как в ядрах сервера, так и в клиентских ядрах. Однако с помощью очередей и каналов сообщений ядра сервера могут отправлять сообщения и продолжать свою работу, не ожидая блокировки. Замедляет ли необходимость блокировки производительность общей памяти по очередям сообщений и каналам в сценарии описанного выше типа?

Answer 1

(1) Не существует автоматического c механизма для уведомления потоков / процессов о том, что данные были записаны в ячейку памяти. Вам придется использовать какой-то другой механизм для уведомлений.

(2) У вас есть настройка для нескольких производителей / одного потребителя (MPS C). Реализация очереди без блокировки MPS C не тривиальна. Вам следует обратить особое внимание на выполнение операций atomi c compare-and-swap (CAS) в правильном порядке с правильным упорядочением памяти, и вы должны знать, как избежать ложного совместного использования строк кэша. Смотрите https://en.cppreference.com/w/c/atomic для поддержки операций atomi c в C11 и читайте о барьерах памяти. Еще одно хорошее чтение - статья о Disruptor в http://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf.

(3) Размер ваших данных (50 * 750) небольшой. Скорее всего, все это помещается в кэш, и у вас не будет проблем с пропускной способностью доступа к нему. Блокировка против конвейера против очереди сообщений: ни одна из них не является бесплатной во время конфликта и когда очередь заполнена или пуста.

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