Приняла ли дилемма "передача сообщений / совместное состояние" (параллелизм и распространение) форму "Холион"?

Question

Я не слишком хорошо осведомлен о состоянии дискуссии о том, какая модель лучше, поэтому я хотел бы задать довольно прямой вопрос: похоже ли это на две противоположные точки зрения, которые действительно вызвали спор? Например, как ООП на основе прототипа / класса или динамическая или статическая типизация

(хотя это не совсем подходящие примеры, я просто не знаю, как выразить свой вопрос более четко)

Answer 1

Из Википедии

В некоторых параллельных вычислительных системах связь между параллельными компонентами скрыта от программиста (например, посредством использования фьючерсов), в то время как в других она должна обрабатываться явно. Явное общение можно разделить на два класса:

Обмен совместно используемой памятью Параллельные компоненты взаимодействуют, изменяя содержимое областей совместно используемой памяти (на примере Java и C#). Этот стиль параллельного программирования обычно требует применения некоторой формы блокировки (например, мьютексов, семафоров или мониторов) для координации между потоками.

Передачасообщений. Параллельные компоненты обмениваются сообщениями (например, Erlang и occam). Обмен сообщениями может осуществляться асинхронно или может использовать стиль рандеву, в котором отправитель блокируется до получения сообщения. Асинхронная передача сообщений может быть надежной или ненадежной (иногда ее называют "пошли и молись"). Параллельность передачи сообщений, как правило, гораздо легче рассуждать, чем параллельная совместная память, и обычно считается более надежной формой параллельного программирования. Доступно множество математических теорий для понимания и анализа систем передачи сообщений, включая модель актора и различные исчисления процессов. Передача сообщений может быть эффективно реализована на симметричных мультипроцессорах с общей когерентной памятью или без нее.

Общая память и параллелизм передачи сообщений имеют разные характеристики производительности; как правило (хотя и не всегда), издержки памяти на процесс и издержки переключения задач ниже в системе передачи сообщений, но издержки самой передачи сообщений больше, чем для вызова процедуры. Эти различия часто перекрываются другими факторами производительности. В приведенном выше фрагменте говорится, что асинхронная связь может быть ненадежной, но этого можно избежать, используя систему организации транзакций (JMS через MQSeries, OpenMQ и т. Д.)

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