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

Вот именно поэтому и интересно было бы почитать классиков по данному вопросу

С книгами мне лично было сложно... начинал читать несколько книг, но каждый раз не хватало понимания "зачем это", что бы довести до какого-то результата. Зато вот по этим курсам, которые ведет Одерски (создатель Скалы) всё пошло как по маслу. Одерски - вполне классик.

Ой! Напоминает планы построения коммунизма

Этого достаточно.

Вопрос не в длинне блокировки (она и в обычных мьютексах может быть кототкой), а в их принципиальном наличии

Опять ой! Это опять не так. Например, переменная counter меняется в 2х задачах:

Если высокоприоритетная задача вытеснит низкоприоритетную после if, то после ее окончания и возобновления низкоприоритетной задачи, в counter в конце концов окажется -5, чего никогда не может случиться, если бы if выполнялся атомарно (или под заблокированными прерываниями). Что и требовалось доказать

Вы опять подменяете условия задачи на другие. Сделать неблокирующее помещение в очередь (в данном случае) позволит избежать deadlock'а. Но это совершенно не значит, что в SST вообще не может быть deadlock'а. дной постановке задачи (с блокирующим помещением в очередь) он есть. И в SST он никуда не денется.

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


Если ваш process захочет записать 3 байта в другую очередь (как в исходной задаче), то и ваш 'такой' код тоже повиснет

Он и без вашего участия сам заблокируется

Теперь сравните размер - 5 строк в исходном коде и более 10 в SST. А если вспомнить, что is_ready_to_receive_packet тоже мог ждать, то код еще вырастет

Не любая, а с более менее простой структурой управления (в идеале вообще линейная) и с небольшим набором возможных состояний. Для МК это так. Для систем побольше, уже не так.


Дались вам эти циклы. Далеко не все из них состоит. И преимущество thread перед SST состоит не в том, что в thread программе можно написать бесконечный цикл, а в том, что thread сохраняет текущий контекст выполнения, включая стек вызовов со всеми переменными. В SST вам придется самому организовывать хранение контекста: переменные на внутренних переменных класса (или в захваченных лямбдой переменных), а положение в графе управления (call stack в thread) - явным дроблением и выделением всех возможных точек входа/выхода и переходов.

Наличие или отсуствие синхронизации, deadlock'ов и разделяемых переменных не играет никакой роли - и thread и SST модели делают это концептуально одинаково.

Да, это все огрызки. С ними возимся не из за того, что не можем дорасти до нормального ФП, а из за того, что железо, с которым работаем -императивное и слишком слабое и нормальные ФП-языки на нем запустить пока не удается.


Нет, в sst так писать нелься. Не должен counter меняться в 2х задачах.


Пример ситуации можно, когда будет dead-lock?


Почему это он повиснет? Он либо запишет 3 байта, либо не запишет. Как быть в случаи провала записи в очередь решает уже программист, обрабатывая ошибку записи.


Ну это особенность языка, да и то большинство строк - комментарии


Хотелось бы реальный пример такой задачи, мозг потренировать


Это да. но хотелось бы реальную задачу, где именно сохранение контекста необходимо или сильно облегчало бы жизнь.


Да, одинаково, поэтому делают active-object pattern и тогда программа стает такая же, как бы она была написана на SST (если все вызовы асинхронные).

С этим согласен на все 100%. Вот только не уверен, что когда нибудь появится такое железо, где можно будет напрямую ФП запустить

Вспоминается история с PicoJAVA. SUN решил, что если исполнение JAVA байт кода сделать напрямую в железе, то такая штука всех порвет. И сделал. А потом выяснилось, что обычный SPARC этот самый байт код успевает интерпретировать быстрее, чем спец процессор исполнять
Провал был грандиозный Не все можно эффективно на железо положить

Та мощный проц запросто под ФП идет, но я работаю в основном на embedded, cortex-ы там всякие, под них erlang хоть и есть, но ресурсов сжирает много, а под avr-образные вообще такого нет.

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

Так, расписываю подробно (думал, что и так понятно, но видимо нет)
Можем получить deadlock

Возьмите любую MT задачу размером более 10000 строк С/С++

И переписать на SST? Так я таким и занимался, вышло отлично.


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



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

Т.е. SST это такая смирительная рубашка, которая ограничивает возможности програмиста?

То, что вы не видите потенциального deadlock'а, не значит, что его нет. В этом и проблема.
Deadlock будет при заполненных очередях. Когда в событии on_space_avail каждый процесс будет пытаться положить данные в очередь. Т.к. места в очереди нет (после 1го срабатывания on_space_avail) оба процесса будут ожидать пока освободится место для 2го и 3го байта. Но это место никогда не освободится, т.к. только эти самые процессы могут освободить место, читая из очередей. А они не могут, т.к. они не доработали до конца - не все данные помещены в очереди. Deadlock

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


Так процесс всего один - process(B,А ) , и то какой-то странный. Первый(process(A, B ) ) не делает ничего, его можно смело закомментировать, как по мне.
Какую задачу должен решать этот код? Я попытаюсь сделать правильное решение.
deadlock можно и в одном потоке получить только какой в этом смысл?

Ага, но такое ограничение - это черезчур

Почему это? Работают оба процесса. Попробую написать в виде thread кода, в SST переведете сами

Ну такое переливание делается как-то так. deadlock-a нет, есть ошибка записи, которую нужно обработать.

Если этого не сделать, то сообщения перестанут обрабатываться, но эту ситуацию можно исправить на горячую, в отличии от dead-locka на мютексах.

Именно, что 'another way'. Нужно поставить событие на освобождение места в out и в нем пытаться записать (именно это делает оригинальный код)

Это и есть deadlock
deadlock на мьютексах тоже можно разбить на горячую, проблема в том, что система уже находится в некорректном состоянии (что в этом примере, что в мьютексах). Для избежания deadlock'ов нужно перепроектировать систему, а не ломать их 'на горячую'. И это относится как к обычным thread'ам, так и к SST

Так что SST от deadlock'ов не спасает

NB. Уточнение во избежание недопонимания - dedlock это не только взаимная блокировка мьютексов, но и любая взяимная блокировка на каких то ресурсах. От обычной блокировки (например, если пытаться писать в очередь из которой никто не читает) отличается тем, что возникает очень спорадически и невоспроизводим.
NNB. Еще уточнение - 'спасает от dedlockов' обозначает принципиальную невозможность возникновения dedlock'ов в любом случае, а не их отсутвие при правильно написанной программе.

Переполнение очереди - это аналог переполнения стека. Только в первом случаи его можно резолвить софтово, а во втором - это крах системы.
При проектировании блокинг-модели надо дать заведомо достаточно стека. При проектировании SST - заведомо достаточно места в очереди. То есть избегать их переполнения.
Если уж переполнение произошло - нужно сделать восстановление - обычно это потеря данных, запись этого события в лог, и повторная их передача либо просто skip. В случаи с переполнением стека мы даже залогировать это событие не сможем (если нет аппаратной поддержки или кривого и тяжелого монитора стека)

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


Ну такой deadlock(когда система перестает обрабатывать события) можно получить и в одном потоке и даже в функциональном программировании.