История изменений
Исправление byko3y, (текущая версия) :
Второй поток может по завершении транзакции проверить, были ли изменены данные первым потоком и, если изменение было, то делать рестарт
Да, это ленивая модель нормального выполнения. Если быть точным, то ленивость/бойкость может быть разная для нормального выполнения и для разрешения конфликтов. Так вот: что делать, когда конфликт был обнаружен? Я описывал в статье проблему ленивых транзакций при интенсивных конкуренциях задач — в таких ситуациях ленивость при решении конфликтов отвратительнейше работает.
Хотя не совсем ясно, как обойтись без локов в конце транзакции, когда копия данных переносится в источник
Первый исторически документ, который описывал транзакционную память, предлагал использовать атомарный compare-and-swap на единственном указателе на данные. Все варианты compare-and-swap над несколькими ячейками и аппаратных транзакций в итоге сводятся к атомарному изменению единственной ячейки и спинлокам при конфликтах.
Если у второго потока есть какой-то дополнительный побочный эффект, то рестартовать его может быть непросто. Даже если не брать случай с запуском ракеты, то даже какое-нибудь обновление экрана с периодическими мелькающими артефактами вызовет вопросы у пользователя
Ну по поводу GUI как раз проблем нет, потому что нынче, как правило, используется двойная буферизация и выводится только готовая картинка.
То, что могут откуда ни возьмись появиться побочки — да, это проблема, и ей нужно уделять внимание. Я думаю, что случайных повторов транзакций для целей отладки будет достаточно — тем более, что для питона характерна test-driven разработка.
Второй пример взят из игры в героев 3 по сетке, когда игроки играют параллельно до тех пор, пока не видят войска врага. После обнаружения врага происходит рестарт последнего хода (транзакции) и игра переходит в последовательный режим. Здесь рестарт производится только на одну транзакцию (или пару), а дальше заменяется на блокировки
Есть такое в героях? Из того, что я смотрел, я видел ручное задание кол-ва дней с параллельными ходами. рестарт хода выглядит странно, потому что тогда в преимущественном положении оказывается тот, кто быстрее походил и больше узнал о карте.
Я не привязываю мои рассуждения к питону, так как считаю, что он не требовал изменений после версии 2.7. Соответственно, мне уже не важно, кто и что делает с современной версией
Да, не требовал. Но разрабатываемый мной проект довольно бесполезен для какого-то лиспа или другого языка на базе неизменяемых структур данных (в статье приведен пример Clojure). Для статически компилируемых быстрых языков, вроде C/C++, уже есть решения, так что для них мой проект тоже неактуален. Он актуален для медленных языков с требованием гарантий надежности выполнения самого кривого кода — а это Python, PHP, Perl, Ruby, Lua, и прочая скриптовуха.
Исходная версия byko3y, :
Второй поток может по завершении транзакции проверить, были ли изменены данные первым потоком и, если изменение было, то делать рестарт
Да, это ленивая модель нормального выполнения. Если быть точным, то ленивость/бойкость может быть разная для нормального выполнения и для разрешения конфликтов. Так вот: что делать, когда конфликт был обнаружен? Я описывал в статье проблему ленивых транзакций при интенсивных конкуренциях задач — в таких ситуациях ленивость при решении конфликтов отвратительнейше работает.
Хотя не совсем ясно, как обойтись без локов в конце транзакции, когда копия данных переносится в источник
Первый документ, который описывал транзакционную память, предлагал использовать атомарный compare-and-swap на единственном указателе на данные. Все варианты compare-and-swap над несколькими ячейками и аппаратных транзакций в итоге сводятся к атомарному изменению единственной ячейки и спинлокам при конфликтах.
Если у второго потока есть какой-то дополнительный побочный эффект, то рестартовать его может быть непросто. Даже если не брать случай с запуском ракеты, то даже какое-нибудь обновление экрана с периодическими мелькающими артефактами вызовет вопросы у пользователя
Ну по поводу GUI как раз проблем нет, потому что нынче, как правило, используется двойная буферизация и выводится только готовая картинка.
То, что могут откуда ни возьмись появиться побочки — да, это проблема, и ей нужно уделять внимание. Я думаю, что случайных повторов транзакций для целей отладки будет достаточно — тем более, что для питона характерна test-driven разработка.
Второй пример взят из игры в героев 3 по сетке, когда игроки играют параллельно до тех пор, пока не видят войска врага. После обнаружения врага происходит рестарт последнего хода (транзакции) и игра переходит в последовательный режим. Здесь рестарт производится только на одну транзакцию (или пару), а дальше заменяется на блокировки
Есть такое в героях? Из того, что я смотрел, я видел ручное задание кол-ва дней с параллельными ходами. рестарт хода выглядит странно, потому что тогда в преимущественном положении оказывается тот, кто быстрее походил и больше узнал о карте.
Я не привязываю мои рассуждения к питону, так как считаю, что он не требовал изменений после версии 2.7. Соответственно, мне уже не важно, кто и что делает с современной версией
Да, не требовал. Но разрабатываемый мной проект довольно бесполезен для какого-то лиспа или другого языка на базе неизменяемых структур данных (в статье приведен пример Clojure). Для статически компилируемых быстрых языков, вроде C/C++, уже есть решения, так что для них мой проект тоже неактуален. Он актуален для медленных языков с требованием гарантий надежности выполнения самого кривого кода — а это Python, PHP, Perl, Ruby, Lua, и прочая скриптовуха.