LINUX.ORG.RU

Как реализуется синхронизация/блокировка в модели акторов?

 


1

2

Федотов, «Модели параллельного программирования» пишет, что синхронизация/блокировка строятся на базе примитива (сущность-актор<->сообщения). Из доступного списка литературы к Федотову больше понятно не стало. Это же не нужно вводить в модель главного диспетчера блокировок?

Hewitt, A universal modular ACTOR formalism for artificial intelligence 1973:

SYNCHRONIZATION: It provides at least as powerful a synchronization mechanism as the multiple semaphore P operation with no busy waiting and guaranteed first in first out discipline on each resource. Synchronization actors are easier to use and substantiate than semaphores since they are directly tied to the control-data flow.

Больше ничего не нашел.

panzerito ()
Последнее исправление: panzerito (всего исправлений: 1)
Ответ на: комментарий от panzerito

Это же не нужно вводить в модель главного диспетчера блокировок?

Зависит от целей и того, что ты называешь «главным диспетчером блокировок».

А вообще, кастуй анонiмуса. Он знает об акторах всё.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

anonymous ()

Вопрос не понял. Можно расширить контекст, в котором вы используете термин «блокировка»?

eao197 ★★★★★ ()
Ответ на: комментарий от panzerito

Легче не стало. Обработка данных — она разная.

Идет ли речь о том, что какой-то актор владеет некими данными (например, кэшем), к которым хотят обращаться другие акторы? И нужно обеспечить консистентность этих данных? (В традиционной многопоточности это решается посредством spinlock-ов, mutex-ов или semaphore-ов)

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

Скорее всего да.

(В традиционной многопоточности это решается посредством spinlock-ов, mutex-ов или semaphore-ов)

Точно да

Может быть посоветуете книгу, а потом я, возможно, задам не такой глупый вопрос?

panzerito ()
Ответ на: комментарий от eao197

Абстрактную идею с реализацией не путай. Конкретная реализация использует локи и пр. под капотом. Хорошая конкретная реализация при этом тебя не часто этим парит. Хорошая практика - данные immutable, так что бороться с конкурентными изменениями не нужно. Если всё-таки остался «разделяемый» ресурс, то есть его владелец, который по запросу отдаёт нужную инфу (всё тот же message passing).

anonymous ()
Ответ на: комментарий от panzerito

Скорее всего да.

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

Все это станет понятно если представить себе, что каждый актор — это поток исполнения, у которого есть очередь сообщений. Очередь защищена mutex-ом. Для отсылки сообщения нужно захватить mutex, поместить сообщение в очередь, отпустить mutex. Аналогично, при получении сообщения нужно захватить mutex, взять сообщения, освободить mutex. После чего обработать сообщение.

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

Это если на пальцах объяснять. В реальных фреймворках/средах может быть гораздо сложнее, включая использование lock-free очередей для сообщений.

eao197 ★★★★★ ()
Ответ на: комментарий от tailgunner

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

aedeph_ ★★ ()
Ответ на: комментарий от eao197

Да, был неправ, ответил не туда. Топикстартеру: про книжку имхо или Армстронга про Erlang или вводную по Akka. Вначале объясняют шире то, что eao197 выше писал.

anonymous ()
Ответ на: комментарий от aedeph_

Это отчасти ирония. Хотя анонiмус всё же давал ссылки на интересные статьи.

tailgunner ★★★★★ ()
Ответ на: комментарий от aedeph_

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

Модель акторов мощней МТ потому что МТ определяется и реализуется в терминах одели Акторов, но не наоборот. Например, на МТ невозможно *гарантированно* получить рандомное число <бесконечности.

actionpattern ()
Ответ на: комментарий от aedeph_

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

actionpattern ()
Ответ на: комментарий от aedeph_

ты снова продуцируешь какую то тупую парашу. Какие то скалы etc, это не имеет отношения к вычислительным моделям, для тебя эти 2 года прошли впустую, ты ни на йоту не приблизился к концептуальной стороне вопроса.

actionpattern ()
Ответ на: комментарий от actionpattern

ты ни на йоту не приблизился к концептуальной стороне вопроса.

Прости зая, я с недостаточно расширенным для этого сознанием.

aedeph_ ★★ ()

тут нужно понимать одну фундаментальную вещь: в Модели Акторов все происходит реально одновременно, как в жизни, пока твоя жена гладит твои носки, ты завязываешь галстук, и нет никакого переключения(для процессора) между «процессом» жены и «процессом» тебя, все происходит одновременно.

actionpattern ()
Ответ на: комментарий от actionpattern

А может ли в реальной жизни жена гладить носки прямо на вас, пока вы завязываете себе галстук?

eao197 ★★★★★ ()
Ответ на: комментарий от actionpattern

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

anonymous ()
Ответ на: комментарий от actionpattern

а почему нет:)

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

это как то противоречит концепции Акторов?

Есть у меня подозрение, что у вас в голове какая-то своя собственная Модель Акторов, ведомая только вам. И как борьба за разделяемые ресурсы будет противоречить это вашей модели сможете понять (а скорее не понять) только вы сами.

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

И как борьба за разделяемые ресурсы

В модели Акторов нет борьбы за разделяемые ресурсы, в обычном быдлопонимании этого слова. Eg *нет борьбы* за право запостить очередную чушь на этом сайтеге. Любое твое сообщение рано или поздно появится тут. Все эти дедлоки и прочая ахинея — то все не касается Модели, потому что там есть недетерминизм. Неизвестно, кто из боксеров одержит победу, их удары не контролируются *процессором* только неведомый «арбитр» все решает.

actionpattern ()
Ответ на: комментарий от actionpattern

тебе уже предлагали тут как-то решить задачу с поддержанием корректного состояния в условиях, когда сообщения могут приходить а) не попорядку, b) теряться, и все это в «твоих собственных» представлениях о модели акторов (то есть без блокировок и сонхронизаций). Ты слилсо, как обычно. У тебя в голову какая-то кю, короч.

anonymous ()
Ответ на: комментарий от actionpattern

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

eao197 ★★★★★ ()
Ответ на: комментарий от actionpattern

Все эти дедлоки и прочая ахинея — то все не касается Модели, потому что там есть недетерминизм.

Модели может и не касаются, но должны касаться «кишок её реализации», ибо сообщения отображаются целиком, не разбиваясь на части «недетерминировано пришедшим» следующим сообщением? Глубоко внутри модели кто-то же за этим следит?

yyk ★★★★★ ()
Ответ на: комментарий от eao197

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

actionpattern ()
Ответ на: комментарий от yyk

маленький анонiмный гномик. очевидно же.

anonymous ()
Ответ на: комментарий от yyk

Глубоко внутри модели кто-то же за этим следит?

Да, Хьюитт называет его «арбитром». Он принимает решения недетерминированно. Это часть Модели.

actionpattern ()
Ответ на: комментарий от actionpattern

Да, Хьюитт называет его «арбитром». Он принимает решения недетерминированно. Это часть Модели.

Да фиг с ним, меня не волнует КАК этот арбитр принимает решения (смотрит на фазы Луны или еще куда), меня волнует, что он таки должен «заблокировать очередь» (или сам себя), пока обрабатывает очередное «недерменированным образом выбранное сообщение».

yyk ★★★★★ ()
Ответ на: комментарий от actionpattern

Ну т.е. согласно вашей «Модели» ваша жена будет недетерминированно определять, гладить ли ваши носки на гладильной доске или непосредственно на вас. Вот что взгляд правильный делает!

eao197 ★★★★★ ()
Ответ на: комментарий от yyk

Да фиг с ним, меня не волнует КАК этот арбитр принимает решения

Это не важно. Можно по фазам луны, главное, перестать быть адептом лапласа, и принять в свою душу случайность

actionpattern ()
Ответ на: комментарий от eao197

у т.е. согласно вашей «Модели» ваша жена будет недетерминированно определять, гладить ли ваши носки на гладильной доске или непосредственно на вас.

Так оно и есть. Любая жена может недетерминированно принять такое решение, так же как недетерминированно получить за то в глаз, либо, наоборот, профит за оригинальность. Вероятно, ни одна жена не знает, чем то кончится:) Я бы например,оценил бы шутку юмора:)

actionpattern ()
Ответ на: комментарий от actionpattern

Вот только ИРЛ нормальные люди (обычно) создают софт, чтобы он приносил какой-то результат а не страдал херней.

ya-betmen ★★★★★ ()
Ответ на: комментарий от actionpattern

принять в свою душу случайность

Принимать я могу много чего, и не в душу тоже. Мне очень интересно, как в рамках этой модели реализовать ACID.

yyk ★★★★★ ()
Ответ на: комментарий от eao197

Банкиры бы оценили «недетерминированный порядок» платежей от него... А если что не так - иди разбирайся с арбитром или самим Хьюиттом.

yyk ★★★★★ ()
Ответ на: комментарий от yyk

Мне очень интересно, как в рамках этой модели реализовать ACID.

А в чем ты видишь проблему? Будет тебе актор «СУБД» и сообщение «перевести N денег со счета X на счет Y».

tailgunner ★★★★★ ()
Ответ на: комментарий от yyk

Банкиры-то ладно. А вот когда так же начинают оборудованием управлять, самолетами там, или, не дай Бог, оружейными системами... Представишь себе F35, который недетерминированно определяет что делать дальше, так совсем страшно становится.

eao197 ★★★★★ ()
Ответ на: комментарий от tailgunner

В таком виде он и сейчас, можно сказать, есть. Меня интересует - как его написать? Реализовать на модели акторов, в которой отсутствуют блокировки, транзакции со вложенными блокировками и откатами и прочее?

yyk ★★★★★ ()
Ответ на: комментарий от eao197

Представишь себе F35, который недетерминированно определяет что делать дальше, так совсем страшно становится.

Главное, чтобы сначала катапультировал пилота ))

yyk ★★★★★ ()
Ответ на: комментарий от yyk

Главное, чтобы сначала катапультировал пилота ))

Можно сначала кпатапультировать, плотом сорвать фонарь. Недетерминировано ж.

anonymous ()
Ответ на: комментарий от anonymous

Фонарь сорвать после посадки, но не сильно, просто отвалить на сторону. И сразу делать фонарь в виде гроба.

yyk ★★★★★ ()
Ответ на: комментарий от yyk

Реализовать на модели акторов, в которой отсутствуют блокировки, транзакции со вложенными блокировками и откатами и прочее?

Блокировки отсутствуют в модели. Если они тебе нужны, ты реализуешь их поверх модели.

tailgunner ★★★★★ ()
Ответ на: комментарий от yyk

Банкиры бы оценили «недетерминированный порядок» платежей от него.

Банкиры оценят. Счет-- это актор. Он инкапсулирует состояние баланса. В отичии от.

actionpattern ()
Ответ на: комментарий от yyk

и прочее?

в модели Акторов реализуется *все прочее*. В более других моделях не реализуется модель Акторов, она фундаментальна.

actionpattern ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.