История изменений
Исправление alman, (текущая версия) :
А какие профиты когда есть *только* синхронное IPC?
С ходу назову две штуки:
1. Поддержка синхронных (блокирующихся) IPC может быть реализована непосредственно в микропроцессоре. Я сейчас именно этим и занимаюсь в свободное время. Как будет что показать - обязательно покажу.
2. Отпадает необходимость в объектах синхронизации - мьютексы и критические секции становятся попросту ненужны - многопоточный код можно писать пользуясь блокировками в IPC. Для тех, кто слишком стар, чтобы переучиваться, или для legacy кода, все примитивы синхронизации реализуются на основе блокированных сообщений. Получится не очень оптимально, зато ничего не надо переделывать или переучиваться.
Что касается прерываний - «Does not map well to hardware-generated events (interrupts)» - то сложности притянуты за уши. Особенно с учётом приоритетов задач. Наоборот, при правильном обслуживании прерываний, код обработчика становится более простым. Подсказка - проектируйте систему так, чтобы задача обработчик прерывания никогда не был инициатором события. Т.е. драйвер должен уметь только слушать события и отвечать на них. И всё - проблемы обработки прерываний не существет.
Более того, необходимость использования таймеров вообще пропадает. IPC таймаут красиво заменяет необходимость использования таймеров.
В общем, я могу долго, почти бесконечно, сыпать примерами и рассказывать о преимуществах, но не вижу в этом смысла. Если коротко, то можно ответить аллегорией: «Вы не любите кошек? Вы просто не умеете их готовить!».
Исходная версия alman, :
А какие профиты когда есть *только* синхронное IPC?
С ходу назову две штуки:
1. Поддержка синхронных (блокирующихся) IPC может быть реализована непосредственно в микропроцессоре. Я сейчас именно этим и занимаюсь в свободное время. Как будет что показать - обязательно покажу.
2. Отпадает необходимость в объектах синхронизации - мьютексы и критические секции становятся попросту ненужны - многопоточный код можно писать пользуясь блокировками в IPC. Для тех, кто слишком стар, чтобы переучиваться, или для legacy кода, все примитивы синхронизации реализуются на основе блокированных сообщений. Получится не очень оптимально, зато ничего не надо переделывать или переучиваться.
Что касается прерываний - «Does not map well to hardware-generated events (interrupts)» - то сложности притянуты за уши. Особенно с учётом приоритетов задач. Наоборот, при правильном обслуживании прерываний, код обработчика становится более простым. Подсказка - проектируйте сисему так, чтобы задача обработчик прерывания никогда не был инициатором события. Т.е. драйвер должен уметь только слушать события и отвечать на них. И всё - проблемы обработки прерываний не существет.
Более того, необходимость использования таймеров вообще пропадает. IPC таймаут красиво заменяет необходимость использования таймеров.
В общем, я могу долго, почти бесконечно, сыпать примерами и рассказывать о преимуществах, но не вижу в этом смысла. Если коротко, то можно ответить аллегорией: «Вы не любите кошек? Вы просто не умеете их готовить!».