История вопроса
Во время зарождения Rust его разработчики столкнулись с критическим тупиком: такие важные структуры данных, как циклические графы и контейнеры с проверкой заимствований во время выполнения, требовали изменения через совместные ссылки, что прямо противоречило основному постулату языка о эксклюзивном изменяемом доступе. Чтобы решить эту проблему, не нарушая принципа «нулевой стоимости абстракции», был введен UnsafeCell как единственный примитив, который отказывается от гарантии неизменности, связанной с совместными ссылками &T, служа основой для всех безопасных абстракций внутренней изменяемости.
Проблема
Компилятор Rust использует неизменность &T для проведения агрессивных оптимизаций, таких как кэширование значений и перераспределение инструкций, предполагая, что основная память не может измениться на протяжении срока жизни ссылки. UnsafeCell сигнализирует компилятору о том, что его содержимое может изменяться, даже когда оно доступно через совместную ссылку, эффективно отключая эти оптимизации для заключенных данных. Однако эта возможность не распространяется на ссылки, производные от сырого указателя, полученного через UnsafeCell::get(); в тот момент, когда этот указатель преобразуется в &mut T, стандартные правила алиасинга восстанавливаются с абсолютной строгостью.
Решение
Решение требует, чтобы программист соблюдал инвариант, что любая изменяемая ссылка &mut T, созданная из сырого указателя UnsafeCell, должна быть единственным активным путем доступа к этой памяти на протяжении всего ее срока жизни. Эта эксклюзивность запрещает одновременные чтения или записи через любые другие указатели, ссылки или последующие вызовы get() на протяжении существования изменяемой ссылки. UnsafeCell не отключает проверку заимствований; он лишь переносит ответственность за гарантирование временной эксклюзивности и предотвращение гонок данных с компилятора на разработчика.
Описание проблемы
Мы проектировали агрегатор метрик для системы торговли с низкой задержкой, где несколько потоков обновляли счетчики, связанные с конкретными финансовыми инструментами. Общая карта была неизменной после инициализации, но значения метрик требовали частых инкрементов. Использование Mutex<u64> вызвало неприемлемое количество конфликтов, в то время как AtomicU64 оказался недостаточным для сложных составных типов метрик. Нам потребовались обновления без блокировок и выделений памяти для структур, находящихся за указателями Arc, без проверок заимствования во время выполнения.
Рассмотренные решения
Решение 1: Шардированные мьютексы
Мы оценили возможность обернуть каждую метрику в Mutex и распределить их по 256 шартам, чтобы уменьшить количество конфликтов. Этот подход предложил простую безопасность и легко поддерживаемый код. Тем не менее, профилирование показало, что даже операции Mutex без конфликтов занимали сотни наносекунд из-за системных вызовов futex и протоколов когерентности кэша, что нарушило наш строгий лимит на задержку в субмикросекунду.
Решение 2: AtomicPtr с обернутыми значениями
Другой подход заключался в хранении значений как AtomicPtr<Metric> и использовании циклов сравнения и замены для обновлений. Это устраняло блокировки, но требовало выделения новых экземпляров Box для каждого инкремента, что приводило к серьезному давлению на память и конфликтам с аллокатором. Кроме того, это усложняло рекламацию памяти, требуя указателей опасности или сборки мусора, основанной на эпохах, что значительно увеличивало сложность кода и площадь аудита.
Решение 3: UnsafeCell с выравниванием по кэшу
Мы решили хранить метрики в UnsafeCell<Metric> внутри структур, выровненных по размеру кэша, что гарантировало, что потоки, записывающие в разные шарды, не будут совместно использовать линии кэша. Каждый поток получал сырой указатель через UnsafeCell::get(), преобразовывал его в &mut Metric во время обновления — что было гарантированно безопасным благодаря нашей логике шардирования, обеспечивающей отсутствие доступа другого потока к конкретному слоту — и выполнял мутацию. Это требовало блоков unsafe и формального доказательства того, что нашеconsistent Хэширование гарантировало отсутствие коллизий при одновременном доступе.
Какое решение было выбрано и почему
Мы выбрали решение 3, потому что оно обеспечивало нулевую стоимость абстракции над сырой памятью, одновременно отвечая агрессивным требованиям задержки. Гарантия шардирования служила в качестве ручного доказательства эксклюзивного доступа, что позволяло нам использовать UnsafeCell без накладных расходов на синхронизацию во время выполнения. Мы проверили безопасность с помощью MIRI и модели проверки конкурентности loom, чтобы исчерпывающе убедиться, что не было нарушений алиасинга при всех возможных межпоточностях.
Результат
Реализация достигла задержек обновления менее 100 наносекунд с нулевыми выделениями в горячем пути. Тем не менее, во время последующей рефакторизации возникла тонкая регрессия, когда задача обслуживания случайно перебрала все шарды, не получив неявную блокировку шарда, создав две изменяемые ссылки на одну и ту же метрику. MIRI немедленно отметила это как неопределенное поведение во время CI, подтверждая, что UnsafeCell требует строгой дисциплины, даже когда архитектурное проектирование теоретически гарантирует безопасность.
Почему неопределенное поведение возникает, если одновременно удерживать две изменяемые ссылки, производные от UnsafeCell, даже несмотря на то что UnsafeCell явно выходит за рамки стандартных правил заимствования?
UnsafeCell выходит из гарантии неизменности для совместных ссылок на уровне типа, но он не ослабляет основной инвариант типа &mut T. Когда вы вызываете get(), вы получаете сырой указатель *mut T, который не имеет ограничений по сроку службы или алиасингу. Однако в тот момент, когда вы разыменовываете этот указатель в &mut T, вы утверждаете компилятору, что эта ссылка является эксклюзивной. Создание двух таких ссылок на перекрывающуюся память, даже из одного и того же UnsafeCell, нарушает правило алиасинга XOR мутация, которое лежит в основе модели памяти Rust, что приводит к немедленному неопределенному поведению независимо от того, как были созданы ссылки.
Как MIRI обнаруживает нарушения инвариантов UnsafeCell, и почему код может проходить тесты в производственной среде, но проваливаться под MIRI?
MIRI реализует модель алиасинга Stacked Borrows (или опционально Tree Borrows), которая отслеживает разрешения на доступ к памяти через абстрактные "теги". Когда вы создаете ссылку из UnsafeCell, MIRI назначает уникальный тег. Любая попытка использовать другой тег для доступа к одной и той же памяти, пока первая ссылка активна, является нарушением. Код часто проходит стандартные тесты, потому что аппаратные модели памяти прощают ошибки, и безобидные гонки данных могут не проявляться как сбои на практике. MIRI, однако, строго соблюдает теоретическую модель, улавливая такие нарушения, как недопустимость изменяемой ссылки, создавая совместную ссылку из одного и того же UnsafeCell без надлежащей синхронизации, даже если сборка работает на текущей архитектуре процессора.
Объясните, почему Cell<T> не требует небезопасных блоков для мутации, в то время как UnsafeCell<T> требует, и определите конкретную гарантию безопасности, которая обеспечивает это различие.
Cell<T> достигает внутренней изменяемости без unsafe, никогда не выдавая ссылки на свои внутренние данные; он только допускает копирование значений внутрь (set) или наружу (get) для типов, реализующих Copy, или перемещение их (replace) для типов без копирования. Поскольку Cell никогда не возвращает &T или &mut T к содержащему значению, невозможно нарушить правила алиасинга — нет ссылок, чтобы алиасить. UnsafeCell, напротив, предоставляет get(), который возвращает сырой указатель *mut T, позволяя создавать ссылки. Эта гибкость необходима для сложных мутаций на месте, но полностью перекладывает бремя обеспечения эксклюзивности и предотвращения гонок данных на программиста, требуя наличия unsafe блоков.