Erlang: приоритетное получение - PullRequest
6 голосов
/ 06 июня 2009

Приоритетный прием в Эрланге можно легко реализовать следующим образом:

prio() -> 
  receive 
    {priority, X} -> X 
  after 0 -> 
    receive 
      X -> X 
    end 
  end.

Я читаю статью под названием Priority Messaging made Easy , в которой описывается следующая проблема:

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

Я не совсем понимаю.

Вопрос (1): Я предполагаю, что внутренний блокирующий прием будет «вызван» (то есть возобновлен), как только одно сообщение поступит в очередь сообщений, верно? Реально ли предположить, что за короткое время, необходимое для возобновления приема из внутренней блокировки, в очереди уже будет целая куча сообщений?

Вопрос (2): Кроме того, наихудший сценарий описывается как очередь с одним обычным сообщением и большим количеством приоритетных сообщений. Поскольку все пункты приема сначала проверяются по первому сообщению в очереди, а затем по второму сообщению в очереди, ... (источник: эта книга , стр. 69-70) не должно этого be: много обычных сообщений с приоритетным сообщением в конце очереди?

Ответы [ 4 ]

5 голосов
/ 06 июня 2009

Erlang является радикально параллельным языком, нет причины, по которой вы не могли бы отправить несколько сообщений в одно и то же время. Делать предположения в духе «О, это быстро - очень маловероятно, что другие потоки будут делать что-то, что конфликтует за это короткое время» - это по сути то же самое, что закрывать глаза и говорить: «Нет такой вещи, как условия гонки, есть нет такой вещи, как условия гонки ... "

4 голосов
/ 07 июня 2009

Вкл. (1): Можно ли сделать это предположение, зависит от деталей вашей ситуации. Например, все другие процессы, возможно, ожидали, что что-то произойдет, прежде чем отправлять вам свои сообщения.

Вкл. (2): На самом деле, мне кажется, что наихудшим случаем были бы нет приоритетных сообщений, поскольку почтовый ящик должен был бы каждый раз проходить: ? "

1 голос
/ 08 июня 2009

Согласно справочнику erlang получение обходов почтового ящика в порядке времени. и блокирует, пока сообщение не соответствует одному из пунктов.

Учитывая, что звучит так, будто внутреннее получатель будет блокироваться, пока не получит соответствующее сообщение. Из-за этого вы можете на самом деле составлять приоритетные сообщения, ожидая неприоритетных сообщений, что противоположно тому, что вы хотите.

Слишком далеко выходят из этого затруднительного положения новое предложение после внутреннего получения. Или всегда совпадать во внутреннем рецепте.

Хотя, глядя на их функции, внутреннее предложение должно всегда совпадать, но я предполагаю, что это то, о чем они говорили.

0 голосов
/ 09 июня 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...