правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
главный и единственный shared state в beam - это ets. как результат - ets обязательно нужно уметь использовать и понимать
если нужно синхронизированная запись и несинхронизированное чтение - перед ets ставится генсервер, через который идет вся запись, это стандартный паттерн.
Зависит от специфики данных и доступа: С асинхронным доступом: Для данных общего вида (типа структуры, тупплы разных размеров и типов), то ets если на одной ноде crdt на GenServer, mnesia, crdt на ets если на разных Если это какие-то инты, то есть atomics и counters Если это кэш по таймауту/переполнению, то есть Cachex С синхронным доступом Можно ets с read_concurrecny / write_concurrency false Можно генсервер
Обсуждают сегодня