В Rust unsafe блок используется для выполнения операций, которые компилятор считает потенциально небезопасными, и за корректность которых теперь отвечает программист, а не система типов. В контексте многопоточности unsafe открывает доступ к низкоуровневым операциям, которые могут привести к гонкам данных или неопределённому поведению, если использовать их неправильно.

Что делает код unsafe в Rust

Блок unsafe позволяет:

• разыменовывать сырые указатели (*const T, *mut T);

• вызывать unsafe функции;

• изменять неизменяемые данные (через static mut);

• обращаться к внешним функциям (через FFI);

• реализовывать unsafe трейты;

• обходить правила владения, заимствования и времён жизни.

Однако сам по себе unsafe блок не отключает проверку владения или заимствования во всём коде — он просто разрешает локально делать то, что Rust в обычном режиме запретил бы на этапе компиляции.

Как unsafe связан с многопоточностью

В многопоточном контексте unsafe используется, когда нужно реализовать низкоуровневую синхронизацию или передавать данные между потоками без гарантий, которые обычно предоставляет типовая система Rust.

Проблема: гонки данных (data races)

Rust гарантирует на уровне компиляции, что не может быть одновременного доступа по &mut T и &T из разных потоков. Однако в unsafe коде вы можете обойти эту защиту — и именно здесь возникает риск гонок данных.

Типичный пример: вы хотите поделиться доступом к данным между потоками без использования стандартных абстракций вроде Mutex<T> или Arc<Mutex.

Примеры использования unsafe в многопоточности

1. Реализация собственных примитивов синхронизации

Разработчики стандартной библиотеки и низкоуровневых библиотек (например, parking_lot) используют unsafe при создании:

• блокировок (spinlock, rwlock, semaphore);

• CAS-операций (compare_and_swap);

• очередей без блокировок (lock-free queues);

• атомарных контейнеров (AtomicPtr, AtomicUsize и т.д.).

Во всех этих случаях unsafe используется для:

• работы с указателями и кастами;

• ручного управления памятью;

• управления порядком видимости операций (memory ordering).

Пример:

use std::sync::atomic::{AtomicUsize, Ordering};
static mut COUNTER: usize = 0;
static FLAG: AtomicUsize = AtomicUsize::new(0);
fn increment() {
unsafe {
// небезопасный доступ к статической переменной
COUNTER += 1;
FLAG.store(1, Ordering::SeqCst);
}
}

В этом коде потенциально может возникнуть гонка, если COUNTER будет изменяться из нескольких потоков одновременно. Компилятор не даст гарантии безопасности, потому что static mut не защищён от параллельного доступа.

2. Оптимизация без блокировок (lock-free)

unsafe используется для реализации алгоритмов с минимальной синхронизацией (lock-free, wait-free), когда вы хотите избежать блокировок (Mutex, RwLock), чтобы достичь максимальной производительности и масштабируемости.

Пример — использование std::ptr::NonNull, AtomicPtr, сырой аллокации и ручной очистки памяти.

3. Передача данных между потоками с ручным управлением временем жизни

Вы можете использовать unsafe, чтобы поделиться ссылками между потоками, если гарантируете вручную, что:

• данные не будут изменены одновременно;

• ссылка не станет "висячей" (dangling reference);

• владение и drop будут корректно соблюдены.

Почему это опасно

Ошибки в unsafe-коде не определяются компилятором. Если вы нарушите инварианты:

• получите непредсказуемое поведение;

• возможны гонки данных, утечки памяти, падения программы;

• сложно отлаживать и воспроизводить ошибки;

• компилятор может проводить невалидные оптимизации, если считает, что правила Rust соблюдены, хотя это не так.

Пример неправильного unsafe использования:

use std::thread;
static mut GLOBAL: u32 = 0;
fn main() {
let t1 = thread::spawn(|| unsafe {
for _ in 0..1_000_000 {
GLOBAL += 1;
}
});
let t2 = thread::spawn(|| unsafe {
for _ in 0..1_000_000 {
GLOBAL += 1;
}
});
t1.join().unwrap();
t2.join().unwrap();
println!("GLOBAL = {}", unsafe { GLOBAL });
}

Здесь два потока одновременно увеличивают GLOBAL — возникает гонка данных, результат непредсказуем.

Когда можно и нужно использовать unsafe в многопоточности

• Когда вы реализуете свою абстракцию, скрывающую unsafe и предоставляющую безопасный API.

• Когда стандартные средства синхронизации не подходят по производительности или ограничениям.

• Когда вы уверены в глубоком понимании модели памяти, владения, жизненных циклов и aliasing-правил Rust.

• При интеграции с внешним кодом (например, через FFI или вызовы системных функций).

Как минимизировать риск

• Ограничьте область unsafe-блока до минимально необходимого участка.

• Документируйте инварианты: что должно быть истинным, чтобы unsafe код оставался безопасным.

• Покройте API тестами, особенно многопоточными.

• Используйте библиотеки и типы из экосистемы Rust (Arc, Mutex, RwLock, Atomic*), где возможно.

• Рассмотрите применение unsafe только во внутренней реализации, а для пользователя оставьте только safe интерфейс.

Таким образом, unsafe в многопоточном контексте даёт гибкость и контроль на низком уровне, но требует максимальной дисциплины, глубокой экспертизы и строгого соблюдения правил безопасности, которые Rust обычно обеспечивает автоматически.