Why do ⁠ReadHalf and ⁠WriteHalf require T: Sync⁠ to implement Sync in tokio-util

[Orvaxis]

Hello everyone,

I’m currently learning Rust and working on some I/O-related demos using Tokio. While exploring the split functionality provided by tokio-util, I encountered an issue: when I try to split a type T that implements Send but not Sync, I get a compilation error saying that ReadHalf or WriteHalf does not implement Sync.

This surprised me, because when I checked the source code, I noticed that these types internally use std::sync::Mutex, which I assumed would make them thread-safe. However, I later discovered that both ReadHalf and WriteHalf use an unsafe block to implement Sync, but only if T: Sync.

Here are my questions:

1.Why do ReadHalf and WriteHalf require T: Sync to implement Sync, even though they wrap T inside a Mutex? My type is Send, and I’m not accessing T concurrently outside of the Mutex. Is there a specific safety or design reason for this restriction?

2.Why doesn’t the compiler automatically derive Sync for ReadHalf / WriteHalf, relying on the safety of the Mutex? Why does Tokio use a manual unsafe impl Sync for ReadHalf and explicitly require T: Sync? Isn’t the Mutex supposed to guarantee thread-safety regardless of whether T is Sync?

[For8stt]

Your intuition about Mutex<T> is mostly right: a mutex can make T: Send safe to access from multiple threads.

But ReadHalf<T> / WriteHalf<T> don’t rely on auto-derived Sync here. Tokio has explicit unsafe impls:

unsafe impl<T: Send> Send for ReadHalf<T> {}
unsafe impl<T: Send> Send for WriteHalf<T> {}

unsafe impl<T: Sync> Sync for ReadHalf<T> {}
unsafe impl<T: Sync> Sync for WriteHalf<T> {}

So the compiler is not “figuring it out” from the internal Mutex<T>. Tokio is choosing a stricter public auto-trait contract.

In practice, for the common use case you usually don’t need Sync anyway. If you split a stream and move the read half into one task and the write half into another task, Send is the important bound:

let (read_half, write_half) = tokio::io::split(stream);

tokio::spawn(async move {
    // use read_half here
});

tokio::spawn(async move {
    // use write_half here
});

Sync only matters if you want to share references to the same half across threads, e.g. &ReadHalf<T> being Send. That’s not usually needed, since AsyncRead / AsyncWrite polling needs &mut self anyway.

If your own code requires Sync, I’d first check whether that bound is actually necessary. Very often Send + 'static is enough.

If you really need shared access, wrap the half outside:

use std::sync::{Arc, Mutex};

let read_half = Arc::new(Mutex::new(read_half));

Then the wrapper can be Sync as long as the half is Send.

So tl;dr: the internal mutex could allow a looser bound, but Tokio’s public impl is intentionally/conservatively T: Sync. For normal split usage, avoid requiring Sync and just move the halves into tasks.