Начиная с версии Swift 5.5 появился новый ссылочный тип (reference type) - акторы. В данной статье будет рассказано, для чего их добавили и какую роль они выполняют.
Для того чтобы узнать, в каких случаях используются акторы, давайте рассмотрим типичный пример data race с использованием non-thread safe коллекции.
Здесь представлен класс Library которые выступает в качестве "контейнера" для объектов класса Book. Данный код работает корректно в однопоточной среде. Для многопоточного приложения данная реализация будет аварийно завершать программу.
Существует множество способов для устранения этой проблемы. Одним из них - это создание приватной concurrent очереди и методы add(_ book:) и get(name:) обернуть в синхронный вызов данной очереди. Очевидным минусом данного подхода является производительность. Во время выполнения одного из методов, второй будет дожидаться окончания его завершения.
Второй способ устранения данной патологии - это реализация SWMR подхода, однако реализация чуть усложняется с использованием dispatch_barrier.
Для устранения всех рассмотренных недостатков как раз и вступают в игру акторы. Акторы, как уже упоминалось ранее, являются ссылочным типом, а так же они синхронизируют все вызовы к методам и свойствам. Это означает что только один вызывающий объект имеет атомарный доступ к операциям которые предоставляет актор. Нам достаточно лишь поменять тип у Library для получения этих преимуществ.
Одного лишь этого изменения достаточно чтобы сделать данный контейнер потокобезопасным. Теперь можно использовать данный класс в многопоточной среде не опасаясь data race.
Так же, стоит учесть, что взаимодействовать с акторами мы можем только в асинхронном режиме, а именно вызывать методы add(_ book:) или get(name:) мы должны в методе с async семантикой:
В заключении стоит отметить, что акторы являются удобным способом для предоставления потокобезопасности. Однако, как отмечалось ранее, все обращения к методам актора должны выполняться в асинхронной среде, что потенциально может усложнить поддержку и понимание кодовой базы.
Отличный пример асинхронного кода! Спасибо
Комментарий недоступен
В стандартной акторной модели, как правило содержится очередь операций. Так вот в данном случае данная очередь избавляет нас от тех проблем, которые были затронуты в статье, а именно операция на входе ждёт пока завершится текущая операция в акторе.
Так же, ключевое слово await тоже можно рассматривать как отправку сообщений в стандартной акторной модели.
Комментарий недоступен
Я полагаю что нейминг был выбран исходя из того, на "что из существующих механизмов это больше всего похоже" :)
С точки зрения алгоритмов и структур данных, блокировка get() и add() в этом примере несимметрична. Предполагая, что book - стандартная хеш-таблица, вызовы add() блокируют друг друга и get(). А вот get() друг друга не блокируют, потокобезопасно читать можно сколько угодно. Интересно, учитывает ли этот факт реализация Actor, и учитывает ли программист на Swift, если ему достаточно только применить Actor.
Вся проблема в том, что нету гарантий того, что не будет производится одновременно чтение и запись. И в таком случае чтение не может быть безопасным, если по этому же самому ключу в таблице будет происходить запись новых данных.
Комментарий недоступен
Да, такое конечно можно реализовать, как минимум с помощью барьеров которые встроены в libdispatch
+ ко всему, в любом случае, в классической (и правильной) парадигме RW мьютексов - операция записи должна дождаться, пока выполнится текущая операция чтения.