Безопасно ли использовать managed_shared_memory из библиотеки наддува для минимизации непредсказуемой задержки? или я должен использовать mmap() для совместного использования памяти?
Управление отображением адресного пространства процесса с помощью mmap или brk - дорогостоящая операция , так что вы захотите минимизируйте количество раз, которое вы используете mmap. mmap является одним из источников непредсказуемой задержки.
managed_shared_memory использует mmap и предоставляет дополнительные функции, которые вам необходимо реализовать при использовании mmap.
Вероятно, для производительности не имеет значения, какую вы используете, так как mmap стоимость будет доминировать.
Также есть rt_signal с каналом от SIGRTMIN до SIGRTMAX безопасно использовать?
Сигналы могут быть не лучшим выбором для IP C, потому что интерфейсы сигналов POSIX подвержены условиям гонки: идентификаторы процессов используются повторно, так что аргумент pid может относиться к полностью другой процесс к тому времени, когда вы звоните sigqueue.
Сигналы поддерживают только направленную связь, без трансляции. Существует также общесистемное ограничение на количество находящихся в очереди сигналов реального времени.
И API для обработки сигналов не удобны, но это недавно изменилось с введением signalfd и pidfd_open.
Относительно простой и надежный IP-адрес с общей памятью на основе сообщений C представляет собой кольцевой буфер сообщений в общей памяти вместе с общей мьютекс памяти и условная переменная.
Boost Interprocess библиотека предоставляет interprocess_mutex и interprocess_condition, а для кольцевого буфера вы можете использовать boost::lockfree::spsc_queue с фиксированным размером.
Кстати, я Я использую их в исправленном preempt-rt ядре linux.
Вам следует посмотреть Kernel Recipes 2016 - Кому нужна операционная система реального времени (а не вы!) - Стивен Ростедт . Реальное время в основном означает медленный, но с гарантированными сроками.