взаимные блокировки

Потому что, даже курильшик это более сложная система, чем комп с софтом или, тем более, чем anonimous c portquest2016.

То, что ты описал, в CS тоже есть и приводит к live lock :) Решается при помощи рандома, например в ethernet retransmit time после коллизии. Без рандома приводит к еще какому-то виду лока, не помню, как называется. Но все это требует заранее подумать и написать дополнительный код. А программисты этого не любят, а когда все же думают, то умудряются избегать дедлоков более простыми средствами.

В модели акторов все перечисленные проблемы никуда не деваются и прекрасно существует, только это предпочитают замалчивать. Потому что акторы - это современная серебряная пуля, и проблем в ней быть не должно (дальше по теме акторов: https://ru.wikipedia.org/wiki/Догмат).

Без рандома приводит к еще какому-то виду лока, не помню, как называется.

Spin lock, не?

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

просто надо писать на расте

акторы - это современная серебряная пуля

Спасибо, поржал. И над «современныя», и над «серебряная пуля».

Не, спин-лок это примитив синхронизации, типа мьютекса, но другой.

Тогда почему эта проблема существует в CS?

Если тебе нужен STM, ты знаешь, где его найти.

И почему ее не существует в Модели Акторов?

Существует.

Да! Внедрить mordoboy() за ресурсы в ядро!!

Конкурс на лучшую имплементацию объявляю открытым.

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

уже и так встроено

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

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

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

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

Нет ограничения(фиксированного промежутка времени) на время доставки

receive
  foo ->
    ok
after 
  265 ->
    nok
end,

?

Я не понял. Актор А посылает актору B сообщение, которое доходит до последнего за неопределнное время, вот и все. Ответ, если он предполагается, тоже

С фига ли её не существует в модели акторов? Насколько знаю, там просто эти проблемы решаются управляющими программами (арбитрами).

А в CS делается очень просто: блокировки устанавливаются в строгом последовательном порядке, а снимаются в обратном. Причём порядок для разных тредов одинаков. То есть при существовании мьютексов А и Б любой поток (любое место в программе, которое требует оба данных мьютекса) должен будет сначала занять А, а затем Б, а снимаете сначала Б, затем А. Иначе - криво спроектировали и будете ловить дедлоки. Для определенности - можно использовать порядок, в котором данные мьютексы определены в программе/документации/где-нибудь ещё.

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

Если же ты имел в виду отсутствие _гарантий_ на время доставки, то так и надо было говорить.

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

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

они настолько легко разрешимы

Ах, так дедлоки всегда тривиально разрешимы (захватом ресурсов в одинаковом порядке во всех местах или одновременным захватом всех), главное их вовремя заметить.

Никто не говорит, что такая ситуация не может возникнуть

Говорят, сам видел и слышал.

они врут(c)

в CS делается очень просто: блокировки устанавливаются в строгом последовательном порядке, а снимаются в обратном. Причём порядок для разных тредов одинаков. То есть при существовании мьютексов А и Б любой поток (любое место в программе, которое требует оба данных мьютекса) должен будет сначала занять А, а затем Б, а снимаете сначала Б, затем А. Иначе - криво спроектировали и будете ловить дедлоки. Для определенности - можно использовать порядок, в котором данные мьютексы определены в программе/документации/где-нибудь ещё.

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

Но даже если и решает, то это явно крайне неэффективное решение, процессы будут толпами простаивать

Нет ограничения...

Отсутствие гарантии не является гарантией отсутствия. Весь «недетерменизм» происходит от не предсказуемых накладных расходов на переливание из пустого в порожнее обслуживание инфраструктуры акторов и GC, и в большинстве случаев укладывается в очень короткий разброс по значениям. Поэтому если задачи уже вошли в лив-лок, у них есть неплохой шанс остаться в локе надолго.

И снова повторю: то, что нет гарантии, что задачи выйдут из лока за конечное время, не значит, что они не могут случайно выйти через секунду или через два часа. Но решение лив-лока требует именно такой гарантии.

То что ты говоришь вообще никакого отношения к реальности не имеет. Модель Акторов — это математическая модель, там нет никакого GC, и с чего ты его сюда приплел, вообще не понятно. Ознакомься с темой

Это решение «по учебнику». Так обычно и делается, все работает, дедлоков и ливлоков не возникает, никто не простаивает больше, чем нужно.

там нет реализации модели акторов, то что они там нахреначили не соответствует модели, а назвать как угодно можно.

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

Ознакомься с темой

Лучше ты ознакомься с математикой и логикой.

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

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

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

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

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

Нет, тут обсуждаются Акторы в том виде, в котором они изложены в Модели Акторов ее создателем

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

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

Как правило, просто один процесс на время уступает ресурс другому

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

пример не слишком удачный

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

лень думать

Вся суть всего в двух словах.

просто надо писать на расте

И как это поможет?

Ты забыл слово «создатель» с большой буквы написать.

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

ну, можно проще. Процесс ведь не обязан иметь все требуемые ресурсы для того, чтобы начать делать дела. Допустим, для него важно лишь то, что в конце предполагаемого действия все необходимые ресурсы были им заняты. Тогда, получается, что, допустим, процессу A нужны ресурсы a, b, c. В одном случае, если а занят, он может захватить b и c, а к тому времени как он сделает часть дел, захватить a. Если у него строгое требование к очередности захвата, то он не может начать захват ни с b ни с c. Соответственно он вынужден ждать, когда мог бы действовать. с увеличением числа требуемых ресурсов, время будет расти пропорционально числу требуемых ресурсов. Уже отсюда даже вытекает неэффективность.

А, не знал :)

Это будут разные критические секции. Пойди, книжку какую-нибудь почитай про concurrency и с чем его едят.

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

Из википедии:

Критическая секция выполняет те же задачи, что и мьютекс.

При чем тут критические секции?

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

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

говорим об участках кода

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

дыры и аномалии в мышлении

В точку.

а, ты это ничтожество наслушался, в таком случае, пожалуйте-с в игнор, это для меня как лакмусовая бумажка, вполне годится для идентификации биороботов

Если модель акторов такая крутая, почему она никому не нужна?

Если модель акторов такая крутая, почему она мне не нужна?

Окружающим откуда знать?

Я у ТС спрашиваю, балда.