Конкурентность и async

Отправитель std::sync::mpsc получил ошибку отправки: какое изменение состояния канала она означает?

Сервис запускает синхронную запись через spawn_blocking, после чего отменяет задачу. Что гарантирует abort(), если замыкание уже начало выполняться?

use std::time::Duration;

#[tokio::main]
async fn main() {
    let handle = tokio::task::spawn_blocking(|| {
        std::thread::sleep(Duration::from_secs(5));
        println!("запись завершена");
    });

    handle.abort();
    println!("запрос отменён");
}

В lock-free цикле обновления атомарного счётчика зачем использовать слабое сравнение с обменом, допускающее ложный отказ?

Локальные данные нужно безопасно заимствовать из нескольких потоков, которые гарантированно завершатся до выхода из области видимости: какой механизм Rust делает это возможным?

В чём состоит правильный порядок проверки готовности события и регистрации Waker, предотвращающий потерю пробуждения в future?

Может ли вызов unpark до park привести к вечному блокированию потока Rust?

Как ведёт себя поток Rust, если его JoinHandle уничтожить без вызова join()?

Рассмотрите код. Какую гарантию синхронизации даёт join() в отношении результата атомарной записи?

use std::sync::{Arc, atomic::{AtomicUsize, Ordering}};
use std::thread;

fn main() {
    let value = Arc::new(AtomicUsize::new(0));
    let worker_value = Arc::clone(&value);
    let handle = thread::spawn(move || {
        worker_value.store(42, Ordering::Relaxed);
    });

    handle.join().unwrap();
    println!("{}", value.load(Ordering::Relaxed));
}

При проектировании обмена между двумя потоками каналом sync_channel нулевой ёмкости какое ключевое свойство отличает его от буферизованного канала?

После паники потока, удерживающего std::sync::Mutex, что произойдёт при следующей попытке захватить этот mutex?

В многопоточном Rust поток записывает данные, затем выставляет атомарный флаг готовности, а другой поток читает флаг и данные. Почему для публикации данных пары операций с порядком Relaxed недостаточно?

Чем ожидание нескольких futures внутри одной async-задачи отличается от запуска их как отдельных задач с точки зрения параллельного выполнения?

В однопоточном async runtime CPU-bound future не содержит точек ожидания: почему она может блокировать выполнение других задач?

Во время ожидания сетевого события future возвращает Pending: каким образом Waker обеспечивает её повторную проверку после готовности события?

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

Какой механизм позволяет безопасно использовать Mutex<T> между потоками, даже если T не реализует Sync?

В команде строят пул рабочих потоков, которые должны получать задачи из одной очереди. Какое свойство типа не позволяет передать общий Arc этому коду?

use std::{sync::{mpsc, Arc}, thread};

fn main() {
    let (tx, rx) = mpsc::channel::<u32>();
    let shared_rx = Arc::new(rx);

    for _ in 0..2 {
        let worker_rx = Arc::clone(&shared_rx);
        thread::spawn(move || {
            while let Ok(job) = worker_rx.recv() {
                println!("{job}");
            }
        });
    }

    drop(tx);
}

Рекурсивный async-обход вызывает сам себя; объясните причину ошибки компиляции и способ сделать future конечного размера.

async fn walk(depth: u32) {
    if depth > 0 {
        walk(depth - 1).await;
    }
}

Вам нужно отменять async-задачу во время записи в хранилище: какое свойство операции определяет, останется ли состояние корректным?

После возврата Poll::Ready future можно снова передать исполнителю?