OSDev

Пожалуй, нужно соблюдать закономерность. Если сообщение изменяет состояние или режим работы устройства (конфигурирующее/настраивающее сообщение), то оно должно быть блокируемым, потому что от него зависит выполнение следующих сообщений.
А линейная передача данных может быть в виде посылок.

Не совсем. Пока драйвер будет конфигурировать устройство, он нее будет обрабатывать другие сообщения. И пока не закончит не выполнит следующее действие.

KIV, я тоже так считаю.

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

Наверное, уже не актуально, но напишу как понял.
Смысл приблизительно такой:
Send - отправить сообщение.
Receive - ожидать сообщение.
SendRec - отправить, и сразу перейти в ожидание.*
Signal - отправить уведомление.**
Это набор юниксовых команд.
- В случае синхронного (без буферов сообщений) IPC первые две команды являются блокирующими. Третья используется тогда, когда нужно последовательно вызвать первые две блокирующие команды (а это сложно, веде сразу после первой - блокировка). А четвёртая (Signal) нужна для коротких неблокирующих уведомлений.
- В твоём случае IPC асинхронный. Т.е. отправка сообщения (Send) не является блокирующей. Поэтому в SendRec и Signal отпадает необходимость. Остаётся всего два вызова Send и Receive. Вот только если у процесса-получателя будет заполнена очередь, то отправка сообщения ему должна вызвать блокировку отправителя. А это переход к синхронному IPC. Либо можно оставить Signal, отправка которого - просто пометка в битовой карте получателя типа: отправитель прислал уведомление. А т.к. битовая карта не "переполнится" как буфер, то и бояться нечего. А лучше: переходи на синхронные IPC:)