всё непонятное сложное - пока не разберешься

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

Software Transactional Memory. 😉

Хотя для распределённого игравого стейта на нескольких серваках скорее CRDT подойдут.

не, на одном

ну слушай, походу это что-то крутое. почитаю

На одном тоже можно CRDT и Event Sourcing всякий. Или CQRS какой-нибудь.

Только к потокам это относится постольку поскольку. Т.е. особо и не относится. 😊

паготь, как же так?

ну хз. ты использовал что-то из выше перечисленного?

Такие дела. (c) 😂

STM на Haskell и в примерах на Clojure.

ну т.е. насколько это всё реально применять в проекте? вполне или это те технологии о которых больше говорят чем используют?

Я не знаю, чем Вы занимаетесь, но в распределённых системах Event Sourcing, CQRS и CRDT применяют сплошь и рядом налево и направо. Особенно в базах данных. 🤷‍♀️

STM по факту используют только в Haskell, поскольку на остальных языках она безбожно тормозит.

ладно, согласен. STM довольно крутая штука судя по описанию

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

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

Так CRDT и delta-CRDT это вообще не про потоки, а про то, как синхронизировать общее состояния между работающие узлами, по сути это алгоритм координации. Например есть p2p сеть с некоторой задержкой и нужно синхронизировать работу двух клиентов так, что бы они могли менять данные у себя, и видить изменения другого, при этом не перезаписывая или не теряя состояния, а также в правильной последовательности (скажем для журналирования и возможности отката). Можно ли это использовать для синхронизации потоков? Наверное можно, но зачем такие накладные расходы, когда намного эффективнее использовать read / write memory barrier?

согласен что неэффективно так будет. memory barrier опять хз что такое. надо читать)