Какая проверка позволяет Rust безопасно передать владение значением в другой поток?
Rust разрешает передать владение значением между потоками, если его тип реализует маркерный трейт Send. Это означает, что перемещение значения в другой поток не создаёт угрозы нарушения гарантий безопасной памяти, прежде всего гонки данных через недопустимый общий доступ.
Send относится именно к передаче владения. Он не означает, что значение можно безопасно одновременно использовать из нескольких потоков: для этого важен другой маркерный трейт — Sync.
Rust стремится обеспечить безопасность памяти и отсутствие гонок данных без сборщика мусора и без обязательной синхронизации во время выполнения. В языках с менее строгой моделью памяти передача объекта между потоками может привести к use-after-free, двойному освобождению или одновременной записи из нескольких потоков.
Трейты Send и Sync позволяют выразить эти ограничения на уровне типов. Компилятор проверяет их до запуска программы, поэтому некорректная передача значения обычно становится ошибкой компиляции, а не скрытой ошибкой многопоточного выполнения.
Поток может продолжить работу после завершения функции, создавшей его. Если передать ему ссылку на локальные данные, ссылка может пережить владельца. Если же несколько потоков получат неконтролируемый доступ к одному изменяемому объекту, возникнет гонка данных.
Одного ключевого слова move недостаточно. Оно переносит захват в замыкание, но не делает любой тип пригодным для другого потока: тип самого захватываемого значения и его составляющих должен удовлетворять необходимым ограничениям.
Send — маркерный трейт, обозначающий возможность безопасно переместить значение, принадлежащее одному потоку, в другой. Для большинства типов он выводится автоматически, если все содержащиеся в них поля также являются Send.
Например, String обычно можно передать в другой поток: владеющие буфером данные перемещаются, а прежний владелец перестаёт быть доступен. В отличие от этого, Rc<T> не является Send, поскольку его счётчик ссылок не рассчитан на межпоточное использование.
Send не гарантирует безопасность совместного доступа. Связь между маркерами формулируется так: тип T является Sync, если ссылку &T можно безопасно передать в другой поток; практически это соответствует тому, что &T реализует Send. Для общего владения обычно применяют Arc<T>, но он становится пригодным для потоков только при выполнении ограничений для T, а изменяемый доступ обычно требует Mutex<T>, RwLock<T> или другой синхронизации.
Замыкание, передаваемое в новый поток, как правило, должно владеть захваченными значениями и иметь время жизни 'static. Это отдельные требования: 'static предотвращает зависимость от локальных заимствований, а Send проверяет допустимость перемещения самого значения между потоками.
Небезопасный код может вручную реализовать Send, но это обязанность автора типа. Ошибка в такой реализации способна нарушить гарантии Rust, поэтому ручная реализация допустима только при доказательстве, что внутреннее состояние действительно безопасно переносить между потоками.
Сервис принимает задания и передаёт их рабочим потокам. Вариант с передачей Rc<Задание> не компилируется: Rc использует несинхронизированный счётчик ссылок и не является Send.
Первый вариант — клонировать всё задание для каждого потока. Он прост и не требует общей синхронизации, но может быть дорогим по памяти и времени. Второй вариант — использовать Arc<Задание> для общего неизменяемого состояния; он уменьшает копирование, но требует, чтобы данные были безопасны для совместного чтения и иногда добавляет атомарные операции.
Если рабочие потоки должны изменять общее состояние, подходящим решением будет Arc<Mutex<Состояние>> или Arc<RwLock<Состояние>>. Выбор оправдан тем, что Arc обеспечивает общее владение, а блокировка сериализует изменяющий доступ; цена решения — возможное ожидание блокировки и риск неудачной архитектуры с чрезмерной конкуренцией.
1. Делает ли move-замыкание любое значение пригодным для передачи в поток?
Нет. move меняет способ захвата переменных: замыкание получает владение вместо заимствования. После этого компилятор всё равно проверяет, что тип замыкания реализует Send, а для запускаемого потока обычно также выполняется требование 'static. Например, перемещение Rc<T> в move-замыкание не устраняет проблему отсутствия потокобезопасности Rc<T>.
2. Почему Arc<T> иногда всё равно нельзя передать в другой поток?
Arc<T> безопасно переносит атомарный счётчик общего владения, но не исправляет свойства самого T. Для передачи Arc<T> между потоками T должен быть Send, а для безопасного совместного доступа через Arc<T> обычно требуется также Sync.
Поэтому Arc<RefCell<T>> не становится автоматически потокобезопасным: RefCell<T> использует проверку заимствований во время выполнения без межпоточной синхронизации. Для общего изменяемого состояния применяют, например, Arc<Mutex<T>>.
3. Что означает ручная реализация Send для типа с сырым указателем?
Она означает, что автор типа берёт на себя доказательство: перемещение экземпляра в другой поток не нарушит правила владения, время жизни и синхронизацию доступа к объекту, на который указывает указатель. Сам по себе сырой указатель не предоставляет таких гарантий и не даёт компилятору информации о корректности использования.
Ручная реализация может быть оправдана, если тип строго контролирует владение ресурсом, не допускает некорректного совместного доступа и корректно освобождает ресурс в новом потоке. Ошибка в этих инвариантах превращает безопасный снаружи API в потенциальный источник неопределённого поведения внутри unsafe-реализации.