Краткий ответ

sync_channel с нулевой ёмкостью не хранит сообщения в буфере: отправитель и получатель должны встретиться непосредственно в момент передачи. Вызов send блокируется, пока получатель не будет готов принять значение, поэтому такая передача одновременно выполняет обмен данными и синхронизацию потоков.

Исторический контекст

Буферизованные каналы разделяют отправителя и получателя во времени: производитель может временно опередить потребителя. Однако иногда нужна не очередь сообщений, а явная передача владения между двумя участниками.

Для этого используется модель rendezvous, или синхронного обмена: передача считается выполненной только при наличии готового получателя. Такой подход устраняет скрытое накопление данных и делает момент передачи естественной точкой координации.

Постановка проблемы

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

Неверный выбор приводит либо к неконтролируемому росту задержки и очереди, либо к снижению пропускной способности из-за частых блокировок. Важно также учитывать, что sync_channel относится к синхронному API: его блокирующий send или recv нельзя бездумно выполнять внутри async-задачи.

Подробное решение

Для sync_channel(0) нет промежуточного места хранения сообщения. Отправитель передаёт значение только тогда, когда другой поток уже выполняет ожидание получения или готов немедленно принять сообщение.

После успешного send значение принято получателем, а не просто помещено в очередь. Поэтому успешная отправка означает наличие точки синхронизации между потоками. Если получатель отключён, send завершается ошибкой, как и для других каналов этого семейства.

use std::sync::mpsc::sync_channel;
use std::thread;

fn main() {
    let (tx, rx) = sync_channel::<u32>(0);
    let worker = thread::spawn(move || {
        tx.send(42).unwrap();
        println!("сообщение принято");
    });

    let value = rx.recv().unwrap();
    println!("получено: {value}");
    worker.join().unwrap();
}

В отличие от буферизованного канала, отправитель здесь не может завершить send, оставив значение ждать в канале. При ненулевой ёмкости send блокируется только после заполнения буфера, поэтому канал допускает некоторое временное расхождение скоростей.

Нулевая ёмкость полезна для передачи задания ровно одному готовому обработчику, для handoff-сценариев и для явного ограничения темпа производителя. Компромисс — отсутствие накопления и потенциальная блокировка каждого отправителя до готовности получателя.

Ситуация из практики

В системе один поток создаёт крупные объекты, а другой немедленно записывает их в устройство. Рассматривались три варианта: неограниченный канал, буферизованный канал и sync_channel(0).

Неограниченный канал имел бы высокую кратковременную пропускную способность, но при замедлении устройства мог бы исчерпать память. Буферизованный канал сглаживал бы небольшие пики, однако требовал подбора ёмкости и всё равно допускал рост задержки до заполнения.

Выбран sync_channel(0), поскольку объект нельзя было безопасно и экономично накапливать, а производитель должен был продолжать работу только при фактической готовности записи. В результате память не расходовалась на очередь, а перегрузка устройства сразу проявлялась как остановка производителя.

Если подобную схему нужно встроить в async-сервис, синхронный канал следует обслуживать выделенным потоком или заменить на подходящий async-канал. Иначе блокирующее ожидание может занять поток runtime и задержать выполнение других задач.

Что кандидаты часто упускают

Означает ли нулевая ёмкость, что send и recv выполняются одновременно на уровне инструкций?

Нет. Речь идёт не о побайтовой одновременности, а о логической встрече отправителя и получателя. Планировщик может сначала запустить один поток, затем другой; библиотека обеспечивает, что успешная передача завершится только после согласованного обмена.

Всегда ли sync_channel(0) лучше канала с буфером?

Нет. Он гарантирует строгую синхронизацию, но снижает независимость участников. Если потребитель иногда кратковременно занят, отправитель будет простаивать, хотя небольшой буфер мог бы скрыть такой пик без существенного роста памяти.

Выбор зависит от семантики: для ограничения нагрузки и передачи владения подходит нулевая ёмкость, для сглаживания кратковременных различий в скорости — ограниченный буфер.

Можно ли считать успешный send полноценным механизмом публикации любых данных между потоками?

Для данных, переданных через сам канал, успешный обмен предоставляет необходимую синхронизацию канала: получатель получает именно переданное значение после завершения передачи. Но это не превращает произвольные другие обращения к общей памяти в безопасные.

Общее состояние всё равно должно соблюдать правила Rust: использовать Mutex, атомики или другой корректный механизм синхронизации. Канал синхронизирует передачу сообщения, а не автоматически делает небезопасный доступ к стороннему объекту допустимым.