Rust вводит авто-трейты — такие как Send и Sync — для решения эргономической проблемы ручного доказательства безопасности потоков для каждого составного типа. historically, системным программистам приходилось аннотировать каждую структуру сложными контрактами конкурентности, что было подвержено ошибкам и слишком громоздко. Компилятор решает эту проблему, автоматически реализуя эти трейты для агрегатных типов (структуры, перечисления, кортежи) только в том случае, если все их составные поля реализуют их.
Проблема возникает с сырыми указателями (*const T и *mut T). В отличие от ссылок или умных указателей, сырые указатели не несут семантики владения или алиасинга, которые компилятор может проверить. Они могут указывать на локальное хранилище потока, невыделенную память или общий изменяемый состояние, управляемое внешней синхронизацией. Слепое применение Send или Sync к сырым указателям исключительно на основе T нарушит безопасность памяти, так как компилятор не может гарантировать, что указатель используется правильно через границы потоков.
Решение разделяет логику вывода. Для агрегатов компилятор выполняет структурную рекурсию: он проверяет каждое поле. Для сырых указателей компилятор явно удерживает эти реализации, рассматривая их как непрозрачные, потенциально небезопасные дескрипторы. Это заставляет разработчиков использовать unsafe impl Send или unsafe impl Sync, принимая на себя личную ответственность за соблюдение гарантий безопасности потоков, которые компилятор не может вывести.
use std::ptr::NonNull; // Агрегатный тип struct Container<T> { data: Vec<T>, // Vec<T> является Send, если T является Send index: usize, } // Container<T> автоматически Send, если T: Send // Тип с сырым указателем struct Node<T> { value: T, next: *mut Node<T>, // Сырые указатели нарушают авто-вывод } // Требуется явно согласие unsafe impl<T: Send> Send for Node<T> {} unsafe impl<T: Sync> Sync for Node<T> {}
При разработке безаллоционного, неблокирующего MPMC (многопроизводитель, многопотребитель) кольцевого буфера для приложения высокочастотной торговли мне требовалось, чтобы узлы находились в заранее выделенном массиве, чтобы избежать конфликта jemalloc. Структура Node содержала полезную нагрузку и указатель *mut Node<T> next, образующий инвазивный связный список. При попытке отправить дескриптор буфера в рабочий поток компилятор отклонил код, поскольку Node не реализовала Send, несмотря на то, что я знал, что узлы использовались только через атомарные операции сравнения и обмена.
Я оценил три решения. Первое: заменить сырые указатели на Box<Node<T>>. Это было отвергнуто, поскольку Box подразумевает владение кучей и индивидуальные выделения, что фрагментировало кеш-дружественный кольцевой буфер и вводило задержку выделения, неприемлемую в HFT. Второе: использовать NonNull<Node<T>>, обернутый в AtomicPtr. Хотя AtomicPtr сам по себе является Send, если T является Send, содержащая структура Node все равно не прошла авто-вывод, потому что сырой указатель внутри NonNull (который является оберткой вокруг сырого указателя) блокировал структурную проверку. Третье: вручную реализовать Send и Sync, используя блоки unsafe impl.
Я выбрал третий подход после формальной проверки, что все доступы к указателю next защищены атомарными операциями SeqCst на отдельном индексе состояния, что обеспечивало, что отношения происходит раньше предотвращают гонки данных. Это решение сохранило неблокирующую, безаллоционную архитектуру, удовлетворяя типовой системе Rust. Результатом стал очередной производственный класс, способный обрабатывать миллионы событий в секунду без накладных расходов на мьютекс, хотя это требовало обширных комментариев по БЕЗОПАСНОСТИ для будущих сопровождающих.
Почему сырой указатель на тип Send не реализует автоматически Send?
Кандидаты часто предполагают, что Send является "транзитивным" через все поля, включая сырые указатели. Они не понимают, что сырые указатели являются примитивными типами без внутренних семантик владения. Компилятор не может различать между указателем на локальное хранилище потока и указателем на общий кучу, и не может проверить правила алиасинга. Поэтому *const T и *mut T никогда не реализуют Send или Sync автоматически, независимо от T, заставляя программиста использовать unsafe impl, чтобы взять на себя ответственность за контракт безопасности потоков этого указателя.
Как я могу условно реализовать Send для обобщенной структуры, содержащей небезопасные внутренности?
Многие разработчики предполагают, что unsafe impl должен быть безусловным. На самом деле вы можете написать unsafe impl<T> Send for MyType<T> where T: Send + 'static {}. Это важно для обобщенных контейнеров (например, пользовательская обертка для UnsafeCell), которые должны быть Send только тогда, когда их содержимое является таковым. Кандидаты упускают, что условие where в unsafe impl позволяет такую же выразительную мощь, как и безопасные трейты, обеспечивая, что ограничения безопасности потоков корректно передаются через обобщенный код без чрезмерного ограничения реализации.
Что отличает требования безопасности для реализации Sync и Send для типа с сырыми указателями?
Send требует только, чтобы передача владения значением через границы потоков была безопасной. Для сырого указателя это обычно означает, что перемещение значения адреса безопасно, если объект, на который указывает, является Send. Sync, однако, требует, чтобы совместное использование неизменяемых ссылок (&Self) между потоками было безопасным. Если &Node раскрывает значение сырого указателя (которое может быть разыменовано), и другой поток изменяет объект, на который ссылается, через изменяемую ссылку, это представит собой гонку данных. Поэтому реализации Sync для типов, содержащих сырой указатель, почти всегда требуют доказательства синхронизированного доступа (например, указатель можно использовать только в рамках Mutex или через атомарные операции), в то время как Send может требовать только доказательства уникальной передачи владения.