个人写的自旋锁性能很难超过Mutex

--
👇
Bai-Jinlin: 要不换成自旋锁试试？

要不换成自旋锁试试？

如果值是i8应该不会有问题 但何必自己给自己挖坑 拆分拆分 搞几个原子锁代替不香么

👇
ThalliMega: 基本上肯定会触发data race 不知道会不会有其他的ub

--
👇
Pikachu: 这个真的不会触发什么UB吗？

--
👇
ThalliMega: 如果RwLock的性能不够，应该要考虑unsafe了？

struct Data;

static mut DATA: Data = Data;

fn update_data(new_data: Data) {
  unsafe { DATA = new_data }
}

一种可供参考的轻量级读写锁的的写法，把数据和锁分离，读操作是无锁的，不过可靠性没有Rwlock高，理论上读还是有可能在高并发下出现非预期结果。

use std::sync::Mutex;
use std::thread;

#[derive(Default)]
struct Data {
    field: usize,
    write_lock: Mutex<()>
}

impl Data {
    fn read(&self) -> usize {
        // 如果写的时候不允许读的话，也可以判断后加锁，开销仍然比真正加锁低很多
        // if self.write_lock.is_poisoned() {
        //     let _ = self.write_lock.lock();
        // }
        self.field
    }

    fn write(&mut self, value: usize) {
        let _ = self.write_lock.lock();
        self.field = value;
    }
}

// 自定义struct不能直接static定义，至少需要包一个Option或其他智能指针
static mut DATA: Option<Data> = None;

fn main() {
    unsafe {
        DATA = Some(Data::default());
    }

    let read_thread = thread::spawn(move || {
        unsafe {
            let data = DATA.as_ref().unwrap();
            ...
            data.read();
            ...
        }
    });

    let write_thread = thread::spawn(move || {
        unsafe {
            let data = DATA.as_mut().unwrap();
            ...
            data.write(some_value);
            ...
        }
    });

    ...

}

要保证可靠性，要不然就用Rwlock，要不然就用第三方库arc_swap，arc-swap有点像原子操作，load方法下读性能很高，应该是lockfree的，不过store方法下的写操作性能一般，因为只能整体替换，无法类似写锁那样可变引用后局部修改。Arc<RwLock<_>>中其实主要性能消耗还是在RwLock，Arc本身对性能的消耗其实很小，而且其本身有一定特殊性，甚至在某些场景包上Arc比不包还要快。

基本上肯定会触发data race 不知道会不会有其他的ub

--
👇
Pikachu: 这个真的不会触发什么UB吗？

--
👇
ThalliMega: 如果RwLock的性能不够，应该要考虑unsafe了？

struct Data;

static mut DATA: Data = Data;

fn update_data(new_data: Data) {
  unsafe { DATA = new_data }
}

这个真的不会触发什么UB吗？

--
👇
ThalliMega: 如果RwLock的性能不够，应该要考虑unsafe了？

struct Data;

static mut DATA: Data = Data;

fn update_data(new_data: Data) {
  unsafe { DATA = new_data }
}

core 欢迎你

--
👇
ThalliMega: 如果RwLock的性能不够，应该要考虑unsafe了？

struct Data;

static mut DATA: Data = Data;

fn update_data(new_data: Data) {
  unsafe { DATA = new_data }
}

如果RwLock的性能不够，应该要考虑unsafe了？

struct Data;

static mut DATA: Data = Data;

fn update_data(new_data: Data) {
  unsafe { DATA = new_data }
}

我有一个非常暴力的办法：开20多个mpsc queue，每个consumer对应一个。queue的capacity设成1，如果出现overflow的话把最旧的数据丢弃掉。

每次consumer维护一个thread local。读取数据的时候，先尝试把queue里最新的读出来，同时更新thread local。如果queue是空的，那就直接返回thread local。

缺点是producer要往20多个channel里面写数据……但是既然你已经说了producer端的性能不重要，那应该可以接受？

（不太清楚这叫什么pattern，可能有个比较正式的名字吧？）

是对场景1中有性能影响

--
👇
lsk569937453: 只用Mutex的话，每次读写数据也必须加lock，这样对我的场景2中有性能影响。能不能读数据的时候不加lock?

只用Mutex的话，每次读写数据也必须加lock，这样对我的场景2中有性能影响。能不能读数据的时候不加lock?

你这根本都不是Arc的问题。全局变量用不上Arc。

use std::sync::Mutex;
use std::thread::spawn;

static X: Mutex<i32> = Mutex::new(0);

fn main() {
    let handle1 = spawn(|| {
        X.lock().map(|mut xx| *xx += 1).unwrap();
    });

    let handle2 = spawn(|| {
        X.lock().map(|mut xx| *xx += 1).unwrap();
    });

    handle1.join().unwrap();
    handle2.join().unwrap();
}

RwLock<T> 就行, 全局变量没必要包Arc了