История изменений

Якобы узел (поток) может отказать. Ввод сообщений живучести и перезапуск потока решает этот вопрос

Я пояснил, но наверное недостаточно — не обязательно отказывать с концами, достаточно неопределенного времени ответа. Неопределенное время ответа дает неопределенное время реакции всей системы в целом. То есть, один тормознутый поток превратит весь процесс в тормоза — я довольно часто наблюдал такую ситуацию под форточками. Один из способов решения проблемы — никогда не ждать никаких ответов от потока, а тупо самостоятельно читать его состояние. Но корректно по взаимно определенным протоколам.

Якобы медленное исполнение. Поток отправил сообщение и пошёл по своим делам, а в случае блокировок от тупо греет воздух и ничего не делает. Сообщенческий подход всяко обгоняет блокировочный на многоядерных процессорах, потому что в каждый момент времени работают все ядра процессора

До тех пор, пока не возникает необходимость координации/согласованности данных. Тебе нужен ответ, чтобы принять дальнейшее решение, а ответа нету, потому что, видите ли, процесс занят «полезной работой». Если тебе нужна согласованность — это только блокировки, сериализация, разделяемое состояние. Не нужна — значит, не нужно разделяемое состояние и блокировки. Но в общем случае получить согласованность из несогласованности сложнее, чем потерять эту согласованность.

Тупари запутаются в блокировках с вероятностью 99 процентов, а в отправке/приёме/обработке сообщений всё просто, поэтому будет меньше человеческих ошибок в многопоточном коде

Для этого и нужна транзакционная память, потому она и в конце блокировочной секции статьи.

Якобы узел (поток) может отказать. Ввод сообщений живучести и перезапуск потока решает этот вопрос

Я пояснил, но наверное недостаточно — не обязательно отказывать с концами, достаточно неопределенного времени ответа. Неопределенное время ответа дает неопределенное время реакции всей системы в целом. То есть, один тормознутый поток превратит весь процесс в тормоза — я довольно часто наблюдал такую ситуацию под форточками. Один из способов решения проблемы — никогда не ждать никаких ответов от потока, а тупо самостоятельно читать его состояние. Но корректно по взаимно определенным протоколам.

Якобы медленное исполнение. Поток отправил сообщение и пошёл по своим делам, а в случае блокировок от тупо греет воздух и ничего не делает. Сообщенческий подход всяко обгоняет блокировочный на многоядерных процессорах, потому что в каждый момент времени работают все ядра процессора

До тех пор, пока не возникает необходимость координации/согласованности данных. Тебе нужен ответ, чтобы принять дальнейшее решение, а ответа нету, потому что, видите ли, процесс занят «полезной работой». Если тебе нужна согласованность — это только блокировки, сериализация, разделяемое состояние. Не нужна — значит, не нужно разделяемое состояние и блокировки. Но в общем случае получить согласованность из несогласованности проще, чем потерять эту согласованность.

Тупари запутаются в блокировках с вероятностью 99 процентов, а в отправке/приёме/обработке сообщений всё просто, поэтому будет меньше человеческих ошибок в многопоточном коде

Для этого и нужна транзакционная память, потому она и в конце блокировочной секции статьи.