когда актер не подходит?

Question

Я использую актеры всякий раз, когда мне нужно запустить два потока одновременно.Я никогда не использую потоки явно.

кто-то сказал мне, что актеры довольно тяжелые, и не всегда хорошая идея использовать их.

• Каковы правильные сценарии использования актеров, а когда их нет?

• У некоторых из моих актеров просто есть цикл, но нет реакции,Это хорошая практика?

[EDIT]

• Это плохая практика - использовать Thread.sleep внутри цикла актера?

Answer 1

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

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

См. Распределенные вычисления в Википедии для получения дополнительной информации.

Существует два основных классаиз задач, которые не особенно подходят:

• Задачи, которые сильно зависят от синхронизма

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

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

• Задачи, которые по своей природе параллельные данные

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

  Часть «map» алгоритмов отображения карты подходит для этого случая.

  Хотя актеры могут сделать это, то же самое можетбыть сделано с настройками fork / join с меньшими накладными расходами.В Scala 2.9 будут параллельные коллекции, предназначенные для этого типа задач.

Answer 2

Что ж, легко предположить, что только потому, что запущены два фрагмента кода, это разные потоки следующим образом:

new Thread(work1).start()
new Thread(work2).start()

То, что они должны выполняться одновременно .Конечно, это не обязательно так, и будет определяться, в основном, ОС.Таким образом, вполне возможно, что, разбивая часть последовательной работы на большое количество параллельных суб-вычислений, все, что вы делаете, это создает накладные расходы на создание объектов и переключение контекста.

Однако Фреймворк ForkJoin , который находится под системой акторов Scala, должен соответствующим образом определять размер внутреннего пула потоков.Это устраняет ненужные издержки переключения контекста, оставляя только накладные расходы любого (возможно ненужного) объекта / создания

Answer 3

@ Jus12 - описанный вами сценарий лучше всего обрабатывается с помощью Akka IO . Примеры ввода / вывода, представленные в их документации, просты, малы и легко понятны. Один актер, предоставленный Akka IO, отвечает за ввод-вывод низкого уровня; Вы предоставляете второго актера для мониторинга и восстановления соединения, а третий актер - для выполнения «реального» ввода-вывода.

Тестирование этих актеров также очень просто. Используйте AkkaTestKit и убедитесь, что каждый участник реагирует, как и ожидалось, на очень простой набор входных данных.

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

Answer 4

Согласно редактированию вопроса, кажется, что вы используете Актеры для запуска одной операции, которая не является целью модели актера. Изобретатель модели актера ясно говорит, что «Один актер не является актером» , что означает, что для использования модели актера необходимо использовать ее как целую систему.

Итак, Actor должен запускать код внутри вашего цикла, а не запускать сам цикл. Затем субъект должен (асинхронно) получать сообщения и действовать в соответствии с типом и параметрами сообщения. Думайте об этом как о очереди инструкций, чтобы заставить актера делать вещи.