Как я организую многопоточный доступ к графику?

Ваш подход кажется мне разумным ...

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

Если писатель изменяет подграф A, а другой писатель изменяет отдельный подграф B, но другие операции чтения / записи происходят в подграфе C, где A и B находятся в C, тогда вам необходимо убедиться, что версия подграфа C правильно совпадает с версиями B и A.

Я бы предложил схему блокировки в DAG, которая включает блокировку подграфа для множественного чтения / одной записи из заданного корня. Однако вам нужно будет найти график циклических зависимостей с помощью grep, чтобы убедиться, что вы не попадете в состояние голодания / тупика в пределах графика.

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

Ваш подход к управлению версиями звучит хорошо, если ваши условия блокировки во всех случаях гарантируют, что набор ревизий для узлов в любой момент времени T представляет собой целостное состояние графа. Набор узлов и ревизий в T = {n0, n1, n2, n3} и одновременное изменение ревизий подграфов создадут головную боль при сохранении всего набора ревизий и узлов при интеграле T.

Как dfa Как показано выше , набор узлов и ревизий в какой-то момент представляет собой набор изменений всей структуры. Если он целостен, он представляет всю структуру в определенный момент времени.

Помните: Время,

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

Так что на эту тему не так уж много! Интересный. Просто подумал, что поделюсь.

Эйден Белл и DFA дали очень обстоятельные ответы, поэтому я не буду пытаться их превзойти. :) Но сделаю одно наблюдение, касающееся качества графа DAG и одновременного доступа на запись. Возможно, это уже пришло вам в голову, но эй. :)

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

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

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

Надеюсь, это поможет!

-Агор