| ! | Данная информация предназначена только только для IT-специалистов по системной интеграции модулей БИОСОФТ-М. (см. Руководства пользователя к программным продуктам) |
Для наиболее надежного (но медленного) способа передачи данных между процессами см. Interproc-Post.
Использование разделяемых буферов потенциально намного опасней и сложней отлаживать. Однако оно может обеспечить наибольшую эффективность в некоторых случаях, и предпочтительна или необходима практически во всех случаях передачи потоков приборных сигналов в режиме реального времени.
Достаточно вредная вещь если состояние это более одной переменной и переменные взаимозависимы. При доступе к таким разделяемым структурам важна взаимная блокировка тридов/процессов. Темлпейт для такой блокировки опишу позже.
Еще более сложная ситуация если процессы создают несколько разделяемых буферов и их состояния взаимно зависимы. Тогда универсально инкапсулировать необходимую блокировку и обеспечить надежный доступ к данным не возможно и эта задача оседает на приложение. Важно понимать, что возникающие в результате race conditions буги могут проявляться очень редко, только на отдельных конфигурациях и режимах работы систем делая их одними из самых трудно воспроизводимых но достаточно деструктивных буг.
См. Разделяемый буфер для передачи потоков сигналов между процессами. Циклический как реализацию наиболее широко применимой методики передачи данных через циклический буфер FIFO, Такая реализация не требует взаимных блокировок, достаточно надежна, эффективна и проста в использовании в случае передачи данных по одному или по нескольким независимым каналам.
Проблемы же возникают если если передается несколько зависимых/синхронных потоков данных. Эта проблема адресована в вышеуказанном топике.
| i | Параллельное программирование это вынужденное средство оптимизации всегда снижающее надежность. Его следует избегать везде, где это возможно. |
К сожалению параллельное программирование не масштабируется так же хорошо как однотридовое. Если в последовательной программе мы отладили один буфер как надежно работающий объект а затем сложили несколько таких объектов в аккуратно инкапсулированный массив, то мы можем ожидать работоспособный объект Набор-Буферов. Все возможные логические зависимости между буферами мы можем надежно проконтролировать качественной инкапсуляцией. Дальше юзать результат, вставлять его в еще более сложную систему и не ожидать деградаций.
Этот же подход не пройдет в системе с параллельностью. Инкапсуляция и модульное построение кода не обеспечивают защиты от рейс кондишенов. В параллельной среде объекты не могут более надеяться на то, что их внутренности скрыты за публичными методами. В любой момент параллельный код может изменить содержимое забыв что то заблокировать, журнализировать или синхронизировать. Мутексы тоже не универсальное решение. Единственный надежный мутекс это тот который блокирует процесс от начала и до конца и пока один поток не отработает не запускает другой. И кому это надо?...
В post-пересылках Interproc-Post мы хотя бы сами определяем моменты синхронизации данных, имея возможность в простых сценариях окружить данные инкапсуляцией. (Но опять же таки - не масштабируемой на более сложные случаи когда каналы связи установлены на нескольких уровнях структуры модулей/объектов). При использовании же разделяемой памяти мы имеем худший случай неинкапсулированных глобальных данных в параллельном доступе.