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

Ну это вопрос синхронизации я не понимаю какое отношение это имеет к конкретно обозначенной проблеме отсутствия детерминированного состояния всей системы в какой-то инструкции

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

*кот под журналами* Зачем это тебе?

Не нужен никакой X, есть X1 = 0 и X2 = 1

Если тебе нужен порядок вывода — сделай второй print зависимым от первого явно

И первый print будет принимать на вход 0, второй будет принимать 1

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

Проблема как раз в том, что в случае ошибки нам придется добавлять точки синхронизации, чтобы привести систему в какое-то вменяемое состояние (либо каким-то не очевидным откатывать до состояния). Но ошибка происходит внезапно и произвольно, соответственно нельзя заранее определить, можно ли запустить какую-то задачу.
Банальный пример: в Однопоточном приложении мы генерируем данные, затем их пишем в файл. Время O(N + K). В двупоточном мы можем сократить время до O(max(N, K)), но если на стадии генерации происходит ошибка, то с записанными данными происходит проблема

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

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

Оверхед по памяти, либо ручной подход к каждому случаю. В Однопоточном приложении этих проблем в принципе не возникает

Ну почему же сразу на осдев?
Мне кажется переключаться нужно на что-то с быстрым выхлопом, чтобы видеть свою работу.
Я вот, как уже чуть выше сказал нахожу такое в хардсёрф моделировании, не так давно ещё в shadertoy  начал тыкать на постоянной основе.
Но это всё кому как конечно..

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

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

ну да но ты писал не это изначально, а то что тебе не дает жить отсутвие детерминированного глоабального состояния. Но это не так. Проблемы которые тебе нужно решать они про то чтобы поддержать happens before и ему подобные отношения в многопотоке. dataflow частичное решение, которое не сильно усложняет код относительно однопотока, и при этом оно достаточно эффективно.

Почему невозможно? Скоуп очевиден у всех данных

Ну это не совсем правда не просто так же существуют всякие uml диаграммы и для однопотока тоже

Ну вот эта явная поддержка happens before и есть основная проблема многопоточного приложенич

Которой не существует в детерминированной программе, просто потому что она исполняется последовательно