Data race in dropping something around oneshot channel

[etam]

Version
1.3.0

Platform
Linux etam-librem.lan 5.11.4-1-default #1 SMP Mon Mar 8 05:16:55 UTC 2021 (be77cd2) x86_64 x86_64 x86_64 GNU/Linux

Description
ThreadSanitizer shows data races when using oneshot::channel.

Example code (taken from example):

use tokio::sync::oneshot;

async fn some_computation() -> String {
    "represents the result of the computation".to_string()
}

#[tokio::main]
async fn main() {
    let (tx, rx) = oneshot::channel();

    tokio::spawn(async move {
        let res = some_computation().await;
        tx.send(res).unwrap();
    });

    // Do other work while the computation is happening in the background

    // Wait for the computation result
    let res = rx.await.unwrap();
    println!("{:?}", res);
}

compiled and run with this command:

RUST_LOG=trace RUSTFLAGS="-Z sanitizer=thread" cargo run --target x86_64-unknown-linux-gnu

using rust rustc 1.52.0-nightly (107896c32 2021-03-15)

gave this output: tsan.txt.gz (it's too big to paste here)

Interesting places pointed in backtraces:
https://github.com/tokio-rs/tokio/blob/tokio-1.3.0/tokio/src/sync/oneshot.rs#L702
https://github.com/tokio-rs/tokio/blob/tokio-1.3.0/tokio/src/sync/oneshot.rs#L324
https://github.com/tokio-rs/tokio/blob/tokio-1.3.0/tokio/src/runtime/blocking/pool.rs#L259-L260

[Darksonn]

I run into rust#83045 when I try to compile it with both the latest nightly and the one you specified.

[carllerche]

I am pretty confident this is due to the thread santizer not understanding Arc's memory barriers. It's also a reason we wrote loom to verify Tokio's concurrency primitives.

[carllerche]

I.e. you can get thread-santizer to complain w/ an Arc being dropped from multiple threads.

eg. rust-lang/rust#39608 (comment)

[tmiasko]

The Arc is fully compatible with ThreadSanitizer when rebuilding standard library with env RUSTFLAGS=-Zsanitizer=thread cargo -Zbuild-std.