关于c++:多线程-Rust学习笔记

作者：谢敬伟，江湖人称“刀哥”，20年IT老兵，数据通信网络专家，电信网络架构师，目前任Netwarps开发总监。刀哥在操作系统、网络编程、高并发、高吞吐、高可用性等畛域有多年的实践经验，并对网络及编程等方面的新技术有浓重的趣味。

古代的CPU根本都是多核构造，为了充分利用多核的能力，多线程都是绕不开的话题。无论是同步或是异步编程，与多线程相干的问题始终都是艰难并且容易出错的，实质上是因为多线程程序的复杂性，特地是竞争条件的谬误，使得谬误产生具备肯定的随机性，而随着程序的规模越来越大，解决问题的难度也随之越来越高。

其余语言的做法

C/C++将同步互斥，以及线程通信的问题全副交给了程序员。要害的共享资源个别须要通过Mutex/Semaphone/CondVariable之类的同步原语保障平安。简略地说，就是须要加锁。然而怎么加，在哪儿加，怎么开释，都是程序员的自在。不加也能跑，绝大多数时候，也不会出问题。当程序的负载上来之后，不经意间程序解体了，而后就是苦楚地寻找问题的过程。

Go提供了通过channel的音讯机制来规范化协程之间的通信，然而对于共享资源，做法与C/C++没有什么不同。当然，遇到的问题也是相似。

Rust 做法

与Go相似，Rust 也提出了channel机制用于线程之间的通信。因为Rust 所有权的关系，无奈同时持有多个可变援用，因而channel被分成了rx和tx两局部，应用起来没有Go的那么直观和棘手。事实上，channel的外部实现也是应用原子操作、同步原语对于共享资源的封装。所以，问题的本源仍然在于Rust如何操作共享资源。

Rust 通过所有权以及Type零碎给出了解决问题的一个不同的思路，共享资源的同步与互斥不再是程序员的选项，Rust代码中同步及互斥相干的并发谬误都是编译时谬误，强制程序员在开发时就写出正确的代码，这样远远好过面对在生产环境中顶着压力排查问题的困境。咱们来看一看这所有是如何做到的。

Send，Sync 到底是什么

Rust语言层面通过 std::marker 提供了 Send 和 Sync 两个Trait。个别地说法，Send标记表明类型的所有权能够在线程间传递，Sync标记表明一个实现了Sync 的类型能够平安地在多个线程中领有其值的援用。这段话很费解，为了更好地了解Send 和 Sync，须要看一看这两个束缚到底是怎么被应用的。以下是规范库中std::thread::spawn()的实现：

    pub fn spawn<F, T>(self, f: F) -> io::Result<JoinHandle<T>>    where        F: FnOnce() -> T,        F: Send + 'static,        T: Send + 'static,    {        unsafe { self.spawn_unchecked(f) }    }

能够看到，创立一个线程，须要提供一个闭包，而这个闭包的束缚是 Send ，也就是须要能转移到线程中，闭包返回值T的束缚也是 Send（这个不难理解，线程运行后返回值须要转移回去）。举例说明，以下代码无奈通过编译。

    let a = Rc::new(100);    let h = thread::spawn(move|| {        let b = *a+1;    });    h.join();

编译器指出，std::rc::Rc<i32> cannot be sent between threads safely。起因在于，闭包的实现在外部是由编译器创立一个匿名构造，将捕捉的变量存入此构造。以上代码闭包大抵被翻译成：

struct {    a: Rc::new(100),    ...}

而Rc<T>是不反对 Send 的数据类型，因而该匿名构造，即这个闭包，也不反对 Send ，无奈满足std::thread::spawn()对于F的束缚。

下面代码改用Arc<T>，则编译通过，因为Arc<T>是一种反对 Send的数据类型。然而Arc<T>不容许共享可变援用，如果想实现多线程之间批改共享资源，则须要应用Mutex<T>来包裹数据。代码会改为这个样子：

    let mut a = Arc::new(Mutex::new(100));    let h = thread::spawn(move|| {        let mut shared = a.lock().unwrap();        *shared = 101;    });    h.join();

为什么Mutex<T>能够做到这一点，是否改用RefCell<T>实现雷同性能？答案是否定的。咱们来看一下这几个数据类型的限定：

unsafe impl<T: ?Sized + Sync + Send> Send for Arc<T> {}unsafe impl<T: ?Sized + Sync + Send> Sync for Arc<T> {}unsafe impl<T: ?Sized> Send for RefCell<T> where T: Send {}impl<T: ?Sized> !Sync for RefCell<T> {}unsafe impl<T: ?Sized + Send> Send for Mutex<T> {}unsafe impl<T: ?Sized + Send> Sync for Mutex<T> {}

Arc<T>能够Send，当其包裹的T同时反对Send和Sync。很显著Arc<RefCell<T>>不满足此条件，因为RefCell<T>不反对Sync。而Mutex<T>在其包裹的T反对Send的前提下，满足同时反对Send和Sync。实际上，Mutex<T>的作用就是将一个反对Send的一般数据结构转化为反对Sync，进而能够通过Arc<T>传入线程中。咱们晓得，多线程下访问共享资源须要加锁，所以Mutex::lock()正是这样一个操作，lock()之后便获取到外部数据的可变援用。

通过上述剖析，咱们看到Rust另辟蹊径，利用所有权以及Type零碎在编译时刻解决了多线程共享资源的问题，确实是一个奇妙的设计。

异步代码，协程

异步代码同步互斥问题与同步多线程代码没有实质不同。异步运行库个别提供相似于std::thread::spawn()的形式来创立协程/工作，以下是async-std创立一个协程/工作的API：

pub fn spawn<F, T>(future: F) -> JoinHandle<T>where    F: Future<Output = T> + Send + 'static,    T: Send + 'static,{    Builder::new().spawn(future).expect("cannot spawn task")}

能够看到，与std::thread::spawn()十分类似，闭包换成了Future，而Future要求Send束缚。这意味着参数future必须能够Send。咱们晓得，async语法通过generaror生成了一个状态机驱动的Future，而generaror与闭包相似，捕捉变量，放入一个匿名数据结构。所以这里变量必须也是Send能力满足Future的Send约束条件。试图转移一个Rc<T>进入async block仍然会被编译器回绝。以下代码无奈通过编译：

    let a = Rc::new(100);    let h = task::spawn(async move {        let b = a;    });

此外，在异步代码中，原则上该当防止应用同步的操作从而影响异步代码的运行效率。试想一下，如果Future中调用了std::mutex::lock，则以后线程被挂起，Executor将不再有机会执行其余工作。为此，异步运行库个别提供了相似于规范库的各种同步原语。这些同步原语不会挂起线程，而是当无奈获取资源时返回Poll::Pending，Executor将当前任务挂起，执行其余工作。

完满了么？死锁问题

Rust尽管用一种优雅的形式解决了多线程同步互斥的问题，但这并不能解决程序的逻辑谬误。因而，多线程程序最令人头痛的死锁问题仍然会存在于Rust的代码中。所以说，所谓Rust“无惧并发”是有前提的。至多在目前，看不到编译器能够智能到剖析并解决人类逻辑谬误的程度。当然，届时程序员这个岗位应该也就不存在了...

深圳星链网科科技有限公司（Netwarps），专一于互联网安全存储畛域技术的研发与利用，是先进的平安存储基础设施提供商，次要产品有去中心化文件系统（DFS）、区块链根底平台（SNC）、区块链操作系统（BOS）。
微信公众号：Netwarps