Здравствуйте, eao197, Вы писали:

E>Например, механизм producer/consumer с большими объемами данных. Скажем, видеопроигрыватель, где процесс подкачки данных с диска занимает очередной буфер и заполняет его, а процесс восспроизведения не может получить доступ к буферу до окончания закачки.

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

E>Какие выигрышы (жи/ши пиши через и, а жы/шы — через ы?) даст здесь обмен сообщениями по сравнению с ожиданием на cond_var/mutex-е?

Да никаких. Речь в изначальном посте вообще-то шла о том, как современной программе загрузить десятки процессоров. Описанная тобой задача в принципе не загрузит больше двух.

Речь не идет о том, чтобы Erlang автоматически за тебя что-то сделал. Речь о том, что то же самое делается удобнее. Параллелит-то всё еще программист. Только шанс допустить ошибку куда меньше, чем забыть захватить мьютекс или захватить его на излишне долгое время и тем самым затормозить программу.

Например, какие изменения тебе нужно внести в архитектуру, чтобы проигрыватель мог послать «напоминание» и получить частично заполненный буфер, чтобы пользователь не увидел подвисания картинки, в надежде что задержка чтения временная и вот-вот все нормализуется? Сменить блокирующее ожидание сокета на свой цикл проверки, чтобы был появился шанс проверить флаг?

В архитектуре изолированных процессов, producer получает сообщение от сокета о приеме данных, и добавляет в буфер, или получает сообщение от проигрывателя, и отдает частично заполненный. Расширение делается добавлением всего одного сообщения.