在原子上调用`into_inner()`是否考虑了所有轻松的写入?

Ale*_*ing 4 multithreading rust relaxed-atomics

是否into_inner()返回此示例程序中的所有轻松写入?如果是这样,哪个概念保证了这个?

extern crate crossbeam;

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

fn main() {
    let thread_count = 10;
    let increments_per_thread = 100000;
    let i = AtomicUsize::new(0);

    crossbeam::scope(|scope| {
        for _ in 0..thread_count {
            scope.spawn(|| {
                for _ in 0..increments_per_thread {
                    i.fetch_add(1, Ordering::Relaxed);
                }
            });
        }
    });

    println!(
        "Result of {}*{} increments: {}",
        thread_count,
        increments_per_thread,
        i.into_inner()
    );
}
Run Code Online (Sandbox Code Playgroud)

(https://play.rust-lang.org/?gist=96f49f8eb31a6788b970cf20ec94f800&version=stable)

我知道crossbeam保证所有线程都已完成,并且由于所有权返回到主线程,我也明白没有未完成的借用,但是我看到它的方式,如果没有,仍然可能有未完成的待处理写入CPU,然后在缓存中.

哪个概念保证所有写入都完成,并且所有缓存在into_inner()被调用时都会同步回主线程?是否有可能丢失写入?

use*_*342 5

是否into_inner()返回此示例程序中的所有轻松写入?如果是这样,哪个概念保证了这个?

这不是into_inner保证它,它是join.

什么into_inner保证是自从最后的并发写入(线程,最后一次被丢弃和解包等)以来执行了某些同步,或者原子从未首先发送到另一个线程.这两种情况都足以使读取数据无竞争.joinArctry_unwrap

Crossbeam 文档明确指出join在范围的末尾使用:

通过在作用域退出之前让父线程加入子线程来确保[保证终止的线程].

关于丢失写入:

哪个概念保证所有写入都完成,并且所有缓存在into_inner()被调用时都会同步回主线程?是否有可能丢失写入?

正如文档中的各个 地方所述,Rust继承了原子的C++内存模型.在C++ 11及更高版本中,线程的完成相应的成功返回同步join.这意味着到join完成时,联接线程执行的所有操作必须对调用的线程可见join,因此在此方案中不可能丢失写入.

在原子方面,你可以把a想象join成一个原子的获取读取,线程在它完成执行之前执行了一个发布存储.