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

6次阅读

共计 3388 个字符，预计需要花费 9 分钟才能阅读完成。

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

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

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

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

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

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

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“无惧并发”是有前提的。至多在目前，看不到编译器能够智能到剖析并解决人类逻辑谬误的程度。当然，届时程序员这个岗位应该也就不存在了 …