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

Хотите сказать Дон в игрушки играет - пихает в рабочий ЯП всякие поделки?

maybe it should be debug

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

13.11.1. Сюжет усложняется:
квалификатор shared транзитивен
В главе
8 объясняется,
почему
квалификаторы
const и immutable должны
быть транзитивными
(свойство,
также
известное
как глубина
или
рекурсивность):
каким
бы косвенным
путем
вы ни следовали,
рассматривая
«внутренности
» неизменяемого
объекта,
сами
данные
должны
оставаться
неизменяемыми.
В противном
случае
гарантии,
предоставляемые
квалификатором
immutable, имели
бы силу
комментария
в коде.

там обычно за это базка отвечает, нет?

если не изобретать велосипед, то атомарность операций дает БД, т.е. массив в памяти быть может это ранняя оптимизация?

Зашаренный массив - рудиментарная инмемори базка

ну да, не понимаю в чем проблема, действительно все от задачи зависит, и почтовый ящик отличное решение. пользватель отправляет старое и новое значение, если кто-то изменил возвращаем Err, иначе Ok. Мне кажется чел не с той стороны зашел, надо бы отсюда https://fsharpforfunandprofit.com/posts/fsharp-in-60-seconds/

Спектакль смотрел как-то «Весь Шекспир за один вечер». Просто проассоциировалось.

А если у меня таких боксов будет штук 20? Не приведёт ли это к жутким тормозам? Очереди тасков - это ещё та тёмная магия.

половину слов не понял)

Для задачи с шаред массивом обычного лока хватит, не нужны тут майлбоксы. Пример всё равно искусственный

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

твоя проблема ровно ничем не отличается от апдейта самой обыкновенной SQL таблицы, в твоем случае PKey == id элемента.

Поэтому и упростил до массива

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

как ты понимаешь, SQL сервер должен выстоять даже если будет больше 8 транзакций на запись. я слышал, что такие нагрузки есть в Фейсбуке.