1. это мне потребление памяти точно убъект
2. обращение к различным элементам массива не является независимым. То есть не синхронизированные записи в соседние ячейки могут влиять друг на друга.

ну если есть понимает как оно должно лочиться, то можно делать лок на сегменты)

есть только 1 определение "как оно должно" - jmm. Все остальное - от лукавого.

Ну в zio все ок с jmm будет

В контракте не написано - может поменяться в любой момент.

ну тогда вам на джаву над)

спасибо, я там был, мне хватит

На акке выходит один актор может модифицировать матрицу?

да

Ну такое на зио можно было прост с семафором сделать)

там прямым текстом написано про happens before

и с TReentrantLock

я понимаю, что от события "получение семафора" (через CAS на атомике скорее всего) на одном потоке, через запуск файбера, через возможные попадания файбера в очередь, через цепочку flatMap, до итогового выполнения кода на другом потоке (и, возможно, другом тредпуле), _скорее всего_ протягивается порядок из-за того, что все _скорее всего_ на атомиках (то есть волатайлах), но я не уверен, а капать весь связанный с этим код долго, и этого нет в контрактах, значит может поменяться.

ну это и есть прелесть fp, local reasoning и все дела) не нужно думать о jmm )

конечно все проблемы снимаются через Ref[(Int, Data)], с парой get и set на Ref (с инкрементом версии) внутри семафора - там AtomicReference, то есть гарантию мы таки получим. Но это как раз тот колхоз, который я в итоге заменил на актор

До тех пор пока не воткнулся в принципиально мутабельные данные. И тут все стало печально.
Ну что же, теперь у меня есть аж 3 случая, когда использование голых акторов оправдано =)

не знаю, я бы и через zio сделал

ZIO.fromFuture(_ => actorRef.ask(...)) - вполне себе через zio =)

еще и ask....