AB
Всем привет!
Возник довольно общий вопрос по принципам организации erlang/elixir приложения.
Как правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
Возник довольно общий вопрос по принципам организации erlang/elixir приложения.
Как правильно организовать параллельный доступ к данным или состоянию? Например, ets или другая хеш таблица, какая-то сущность, доступная для чтения и записи, должна конкурентно читаться несколькими потоками.
Первой идеей было использовать GenServer, в его state хранить данные и отвечать через handle. Тогда весь доступ сериализуется, нет параллельности. Можно сразу после получения запроса отдавать управление из handle с noreply и запускать процесс, который дошлет ответ клиенту, но в таком случае не понятно как синхронизироваться.
В классической модели с потоками решением был бы RWLock, который давал бы одновременное чтение и синхронизировал записи.
Как такую задачу решить в акторной модели?
Интересуют как конкртеные ответы как это сделать опрделенными средствами, напримр, на ets (тут кажется можно пропробовать просто доступаться к таблице по глобальному идентификатору, хотя опять же без синхронизации) . Так и более общие, какие-то паттерны. Причем также интересна специфика в отдельных случаях, например когда есть только чтение, чтение и запись read/write-heavy и т.п.
если нужно синхронизированная запись и несинхронизированное чтение - перед ets ставится генсервер, через который идет вся запись, это стандартный паттерн.