Почему сообщения, полученные актером, неупорядочены? - PullRequest
10 голосов
/ 22 апреля 2011

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

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

Ответы [ 4 ]

12 голосов
/ 22 апреля 2011

У меня сложилось впечатление, что если две темы отправят сообщение актеру a, то нет конкретной гарантии относительно того, что актер получит первым. Но если у вас есть код, который выглядит как

a ! "one"
a ! "two"

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

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

9 голосов
/ 22 апреля 2011

Я не осведомлен о причинах, по которым Актеры Scala (во всяком случае, в стандартной библиотеке - есть также реализации Актеров Akka, Lift и Scalaz) выбрали именно эту реализацию. Вероятно, как копия собственных ограничений Эрланга - но без гарантий для связи между двумя отдельными потоками. Или, может быть, с такой гарантией - я бы хотел, чтобы Филипп Халлер был здесь, чтобы комментировать.

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

Цитировать Распределенные вычисления: основы, моделирование и продвинутые темы , Хагит Аттия и Дженнифер Уэлч,

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

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

Более того, даже многопоточная модель на многоядерном процессоре в основном асинхронна, а примитивы, обеспечивающие синхронность, чрезвычайно дороги.

Таким образом, простой ответ на вопрос может быть:

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

Эта модель действительно используется в любой системе, распределенной по TCP / IP, и наиболее эффективна для многоядерного / многопроцессорного оборудования i386 / x64.

3 голосов
/ 23 мая 2011

В следующем простом примере показаны сообщения, поступающие не по порядку очень простому действующему субъекту:

import scala.actors._
import scala.actors.Actor._
import scala.collection.mutable._

val adder = actor {
  loop {
    react {
      case x: Int => println(" Computing " + x); reply(x+2)
      case Exit => println("Exiting"); exit
    }
  }
}

actor {
  for (i <- 1 to 5) {
    println("Sending " + i)
    adder !! (i, { case answer => println("Computed " + i + " -> " + answer) })
  }

  println("Sending Exit")
  adder !! Exit
}

Вот вывод из одного запуска вышеуказанного кода с Scala 2.9.0 final в Windows 64-bitс Sun JDK 1.6.0u25:

Sending 1
Sending 2
Sending 3
Sending 4
Sending 5
Sending Exit
 Computing 1
Computed 1 -> 3
 Computing 4
Computed 4 -> 6
 Computing 3
Computed 3 -> 5
Exiting
2 голосов
/ 22 апреля 2011

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

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

Кто-то, вероятно, имеет даже лучший ответ, чем я.

Edit:

Теперь, когда у меня было время поспать на нем, я думаю, что это условие, которое позволяет создавать гораздо более живую экосистему Актеров. Следовательно, зачем ограничивать одного участника или одного потока или частичное владение потоком из пула потоков? Что если бы кто-то хотел иметь Actor, который мог бы захватить как можно больше потоков, чтобы обработать столько сообщений в своем почтовом ящике, сколько мог?

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

Фу, что твои сны говорят о твоем уме, когда ты спишь.

...