Статья, на мой взгляд, очень хорошая.

Да, там интересные неочевидные мысли 🤔

Ну у меня что-то подобное было - я правда в конце первого разговора с HR-ом (повезло, он спросил это в конце разговора, после того, как понял насколько я могу подходить) - сказал, что их вилка мне не подходит вообще. Но понимаю, что если бы я не сказал бы сразу на что я согласен - мог бы в конце иметь ну хотя бы процентов ещё на 5-10% больше - а в статье приводятся хорошие аргументы как незначительны X% для фирмы и значительны могут быть для отдельного человека. Короче статья - действительно очень полезная. Для Elixir-а оффтопик.

А ещё - у меня до сих пор сохранилось в памяти, как в первой фирме - какую-то мою работу на 2-3 недели шеф продал за годовую мою ЗП тогда - иногда лучше не знать, за сколько твою работу продают другим фирмам))) Но меня тогда впечатлило, когда узнал.

Да ну оффтопик... эликсирщики тоже работают 😄

Вот в хаскелль чатике разговоры о работе были бы оффтопиком...

Блин😂 Тоже подумал об этом😄

Разговоры о работе - это сайд-эффект.

Да и какая может быть работа, если ты пишешь на Хаскелл (шутка).

Ты переоцениваешь епам, тут как и везде от проекта зависит🙃

Люди. Такая вот ситуация, есть некие данные, доступ к которым нужно сделать атомарным. Окай помещаем эти данные (назовем их A) в стейт GenServer.
Далее, другому процессу нужно прочитать A, обработать в зависимости от уже своих данных (назовем их B) и в зависимости от результатов обработки внести изменения в A. И все это надо сделать атомарно.
Получается, что для атомарности, надо передать данные B генсерверу хранящему в стейте данные A, а он уже сам проведет эти обработки и внесет изменения. Казалось бы круто, но беда в том, что данные B имеют достаточно большой объем и представляется нецелесообразным копировать их из процесса в процесс.
Неужто придется таки городить мютекс?

Есть очень много способов решения этой проблемы:
1. Если B может хранить свои данные в области литералов (они очень редко меняются или их можно записать при компиляции), то можно в GenServer A передать анонимную функцию, которая приймет данные A и вернет их модифицированную версию. Копирования при этом не будет.

2. Можно использовать ETS для A с сериализацией доступа. Тогда B может прочитать, мутировать и записать изменения A. Но там может прийтись придумать механизм хендоффа таблицы (можно подсмотреть в коннекшин пулинге Ecto как это делается).

3. Можно сделать механизм блокировки на уровне генсервера, который позволит сделать checkout данных из A по похожему принципу с тем, как работает чекаут в коннешин пулинге. (Только нужно будет мониторить процесс который сделалю чекаут чтобы автоматически завершить лок если он крешнулся или подумать про то как процессы зависят в древе супервайзеров).

Вообще задача слишком абстрактная, не понятно много - это как много, что за данные, насколько дорогие/долгие вычисления и т.п.

Некоторое подобие оптимистического лока можно организовать на ets: select_replace

Все три способа мне известны.
3-й способ как раз и есть фактически мютекс.
1-й не подходит, данные меняются часто и засунуть их в литерал или в какой-нибудь :persistent_term тоже не ахти идея.
Выбор между ets или даже mnesia (транзакций ради) и мютексами. Ну или чем-то еще чего я не знаю.

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

В общем ничего другого, похоже пока не придумано, буду локами делать.

Простейший, как я понимаю тупо на генсервере. Уже даже готовое есть - https://hex.pm/packages/mutex/1.3.1

Почему первому способу нужно редко меняющиеся данные?

посмотрел в кишки там есть поддержка автоматического анлока если лочащий процесс внезапно упадет.

Потому что :persistent_term для изменения данных должен сделать глобальный GC