блокирование каналов по сравнению с асинхронной передачей сообщений
Я заметил два метода к "передаче сообщений". Один я видел, что использование Erlang и другой от Stackless Python. Из того, что я понимаю, вот различие
Стиль Erlang - сообщения отправляются и ставятся в очередь в почтовый ящик процесса получения. Оттуда они удалены в основании FIFO. После того как первый процесс отправляет сообщение, которое это свободно продолжить.
Стиль Python - Процесс очереди для отправки к процессу B. B в настоящее время выполняет некоторое другое действие, таким образом, A замораживается, пока B не готов получить. После того как B открывает канал чтения, A отправляет данные, затем они оба продолжают.
Теперь я вижу профессионалов метода Erlang, являющегося этим, у Вас нет заблокированных процессов. Если B никогда не может получить, A может все еще продолжиться. Однако я заметил в некоторых программах, которые я записал, что для окон сообщения Erlang возможно стать полным сотен (или тысячи) сообщений, так как приток сообщений больше, чем отток.
Теперь я не записал большую программу ни в одной платформе/языке, таким образом, я задаюсь вопросом, Ваши события с этим, и если это - что-то, о чем я должен даже волноваться.
Да, я знаю, что это абстрактно, но я также ищу довольно абстрактные ответы.
2 ответа
Мой опыт программирования на Erlang показывает, что когда вы ожидаете высокой скорости обмена сообщениями (то есть, производитель быстрее потребителя), вы добавляете свой собственный контроль потока. Простой сценарий
- Потребитель будет: посылать сообщение, ждать ответа, затем повторять.
- Производитель будет: ждать сообщения, посылать ack, когда сообщение получено и обработано, затем повторять.
Можно также перевернуть этот сценарий: производитель ждет, пока потребитель придет и возьмет N следующих доступных сообщений.
Эти и другие подходы к управлению потоком могут быть скрыты за функциями, первый в основном уже доступен в gen_server:call/2,3 против gen_server процесса поведения OTP.
Я считаю асинхронный обмен сообщениями, как в Erlang, лучшим подходом, поскольку при высоких задержках вы можете захотеть избежать синхронизации при обмене сообщениями между компьютерами. Тогда можно придумать умные способы реализации управления потоком. Например, требовать подтверждения от потребителя на каждые N сообщений, отправленных производителем, или посылать специальное сообщение "пингуй меня, когда получишь это" время от времени, чтобы подсчитать время пинга.
В широком смысле, это неограниченные очереди против ограниченных очередей. Бесставочный канал можно рассматривать как частный случай очереди с размером 0.
Ограниченные очереди имеют тенденцию к тупику. Два потока/процесса пытаются отправить сообщение друг другу, и оба имеют переполненную очередь.
Беспредельные очереди имеют более тонкие проблемы. Большой почтовый ящик не будет удовлетворять требованиям к задержкам, как вы уже упоминали. Зайдите достаточно далеко, и он в конце концов переполнится; нет такой вещи, как бесконечная память, так что это действительно просто ограниченная очередь с огромным лимитом, которая прерывает процесс при заполнении.
Что лучше? Трудно сказать. Здесь нет простых ответов.