> -- Сергей Губанов писал(а):
> Идеологически правильная многопоточная программа логически организуется точно так же как несколько взаимодействующих через очереди сообщений однопоточных программ. Каждая процедура разумеется выполняется в каком-то одном потоке.Это определяется... точкой зрения. Одна и та же процедура (один и тот же код) может одновременно выполняться во многих потоках. Типичный пример, параллельная обработка массивов данных (или разных частей одного массива). Получается, что если смотреть с точки зрения ядра процессора, то он выполняет одну процедуру, а если смотреть с точки зрения процедуры, то она выполняется на многих ядрах процессоров, во многих потоках. Но, в принципе, Вы пишите совершенно верно.
> -- Сергей Губанов писал(а):
> Разница состоит в том, что в очередь сообщений теперь кладётся не само сообщение, а указатель на него (что на порядки быстрее по скорости), а так же в том, что есть доступные всем для чтения по указателям Большие Общие Данные (что на порядки экономнее по памяти).Строго говоря, эти факторы не всегда дают положительный эффект, ни с точки зрения скорости, ни с точки зрения памяти. Если есть избыточные вычислительные ресурсы (дополнительные ядра), то они могут заниматься оптимизацией очереди и/или распределения памяти (не только для данных, но и памяти выделяемой под задачи/потоки), что позволяет достигать большей производительности и компактности. С другой стороны, размещение указателей вместо сообщений может нарушить изолированность исполнения, что создаст угрозу правильности работы, поскольку, как правило, данные, передаваемые по ссылке, не "обрамляются" "критическими секциями" и т.п. Такие ошибки трудно вылавливать. Другими словами, многопоточность не отменяет решение проблем, связанных с обеспечением изолированности и когерентности, а, следовательно, пользоваться указателями и глобальной памятью надо продуманно и очень аккуратно.

Хорошо, что Вы поднимаете эти вопросы. Для разработчиков, как правило, непривычно смотреть на свои программы со стороны... параллелизма. Одно дело писать алгоритмы, вызывая по мере необходимости подпрограммы, другое дело, писать и оценивать программу, как набор связей между разными частями, каждая из которых в значительной степени [должна быть] автономна по ресурсам. И здесь задача организации и оптимизации совместной и параллельной работы частей... становится труднопреодолимым препятствием для дальнейшего развития.