Иммутабельность важна в данном аспекте только для сообщений. Тогда все хорошо. Причем поскольку у нас сообщение, по сути, вещь в себе (то есть не содержит ссылок, то есть просто шмат памяти), то его можно не собирать сборщиком мусора, а достаточно простого подсчета ссылок. Тогда если у нас прут большие массивы данных из одного потока многим, не нужно дублировать сообщение каждому получателю, достаточно дать каждому из них ссылку на данное сообщение, которое помрет тогда, когда о нем все забудут.
Собственно такая стратегия используется в erlang'e для больших бинарей в сообщениях.
Гм. Выходит что область памяти для сообщений должна быть за пределами областей памяти каждого из процессов (коль мы говорим о полном разделении областей памяти, я буду употреблять термин процесс а не поток). Отправляющий говорит - вот это сообщение отправь вот этим вот. Оно копируется в системный пул сообщений, затем всем остальным раздаются на него указатели. Само сообщение остается read only.
Из минусов — имеем лишнее копирование данных (в обычном случае у нас будет 0 копирований). При этом локов действительно может и не быть вообще (lock free очереди никто не отменял). В общем, зависит от задачи на самом деле. В общем случае отношение производительности одного подхода к другому не определено.
PS. Что в данной архитектуре хорошо - то, что можно смешивать разные языки, со сборщиком мусора, без сборщика мусора и так далее.
PPS. Подозреваю, что мы изобретаем велосипед, и если взять какой-нибудь хрюникс на системе без MMU (а такие бывают, да), и взять какой-нибудь голимый pipe, или unix domain sockets, или другое IPC, то мы получим ровно то же самое.
