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

Сам имею подобную картину в текущем проекте. Есть общая память - буфер сообщений. Один процесс занят тем, что постоянно вычитывает из буфера и пишет в файл (заодно отображает на экране какой-то последний кусок), а много потоков из другого процесса в этот буфер пишут. Каждый поток блокирует общую память не больше, чем на время записи одной строки, даже если длина полного сообщения вынудила разбить его на несколько строк. Изредка есть смешение, но даже при чтении глазами (без автоматического анализа) всё это прекрасно видно и не мешает восприятию. Для справки, логи у нас бывают по 400Мб/час, и компонентов-писателей довольно много.

Зуев рассказывает к каким диким ухищрениям приходилось прибегать при создании компилятора C++.
И конечно, предваряет свой доклад фразой, что он считает язык С++ плохо спроектированным.
https://youtu.be/NVUZ-U2QAbc