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

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

Как async runtime приводит созданный future к выполнению?

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

Представьте, что поток передаёт другому потоку общую ссылку на значение типа T. Какой маркер потокобезопасности обязан реализовывать T?

Разберите последствия выполнения блокирующей синхронной операции внутри async-задачи однопоточного runtime Rust.

Что происходит с async-операцией в Rust, когда её future уничтожают до завершения?

В коде ниже компилятор отвергает создание Pin<&mut F>. Какое свойство async-future делает закрепление в памяти необходимым перед передачей future исполнителю?

use std::future::Future;
use std::pin::Pin;

async fn task() {
    let text = String::from("data");
    async {}.await;
    println!("{text}");
}

fn pollable<F: Future>(mut future: F) {
    let pinned = Pin::new(&mut future);
    let _ = pinned;
}

fn main() {
    pollable(task());
}

После запуска потока компилятор отклоняет этот код. Какое ограничение времени жизни нарушено захваченным значением?

use std::thread;

fn main() {
    let message = String::from("готово");
    let handle = thread::spawn(|| {
        println!("{message}");
    });
    handle.join().unwrap();
}

Разберите ошибку в пользовательском future: почему runtime не сможет гарантированно продолжить выполнение задачи после первой проверки?

В коде поток получает собственное владение Rc<Mutex<i32>>, но компилятор всё равно отклоняет запуск. Объясните, какой механизм делает такую передачу недопустимой.

use std::{rc::Rc, sync::Mutex, thread};

fn main() {
    let counter = Rc::new(Mutex::new(0));
    let worker_counter = Rc::clone(&counter);

    thread::spawn(move || {
        *worker_counter.lock().unwrap() += 1;
    }).join().unwrap();
}

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

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

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

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

В команде строят пул рабочих потоков, которые должны получать задачи из одной очереди. Какое свойство типа не позволяет передать общий 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);
}

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

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

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

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

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

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