advance/concurrency-with-threads/sync1 #736

测试发现确实不加{}有一样的效果。*cflag.lock().unwrap() 相当于连写，实际运行的时候rust应该会进行展开。个人猜测 let _l = cflag.lock().unwrap(); 相当于在函数（这个函数会返回被包裹的bool值）里面创建了一个变量，调用结束后就销毁释放了，所以锁也被drop了。

ANIDENTIFIER Jun 17, 2023 — with giscus

*cflag.lock().unwrap()相当于*Deref::deref(&cflag.lock().unwrap())
注意到这里的cflag.lock().unwrap()也就是一个MutexGuard<bool>类型的值是个临时变量，在这行代码结束后就自动drop了，不需要大括号

aresbit · 2022-04-17T18:31:53Z

aresbit
Apr 17, 2022 — with giscus

可否添加parking_lot的对比

0 replies

mxismean · 2022-04-18T09:53:39Z

mxismean
Apr 18, 2022 — with giscus

Condvar 例子的代码，没看懂执行顺序 👀

3 replies

aly8246 Jul 11, 2022 — with giscus

main线程先执行一次打印，然后notify_one,子线程解开互斥体打印一次，然后设置条件变量为false，主线程又开始执行
子线程的核心是在这个地方获取锁和等待锁
while !m {
//如果没有获取到锁就一直等待获取锁
println!("inner thread waiting lock");
m = *ccond.wait(cflag.lock().unwrap()).unwrap();
println!("inner thread acquire lock");
}
主线程在这个地方
//主锁设置为ok
println!("outside thread waiting lock");
*flag.lock().unwrap() = true;
println!("outside thread acquire lock");

如果把这四个打印加上去就可以清晰的看到主线程和子线程获取锁，打印数据和释放锁的流程

aly8246 Jul 11, 2022 — with giscus

inner thread waiting lock
outside thread waiting lock
outside thread acquire lock
outside counter=1
inner thread acquire lock
inner counter=1

inner thread waiting lock
outside thread waiting lock
outside thread acquire lock
outside counter=2
inner thread acquire lock
inner counter=2

inner thread waiting lock
outside thread waiting lock
outside thread acquire lock
outside counter=3
inner thread acquire lock
inner counter=3

ttsy1995 May 11, 2023 — with giscus

抛开原有的循环逻辑，循环逻辑+多线程执行顺序不太明确，Condvar 我验证了一下，其实就是一收一发，只有调用了notify_one、notify_all, wait 内部才会继续执行。

licq · 2022-07-21T11:46:01Z

licq
Jul 21, 2022 — with giscus

for counter in 1..=3 {
    sleep(Duration::from_millis(1000));
    println!("outside counter: {}", counter);
    *flag.lock().unwrap() = true;
    cond.notify_one();
}

condvar的代码稍微简化了一下，觉得会更清晰些。

1 reply

W2Q3Q1 Sep 30, 2024 — with giscus

这个有虚假唤醒问题吧？

zhouhaoan · 2022-08-14T12:20:59Z

zhouhaoan
Aug 14, 2022 — with giscus

thread_local 还是没弄明白FOO到底是怎么传递的

1 reply

Aresona Aug 18, 2022 — with giscus

并发原语是什么呢？

MrZLeo · 2022-08-30T02:39:17Z

MrZLeo
Aug 30, 2022 — with giscus

Mutex 不用再用 lazy_static! 啦🥳

2 replies

studymachiney Feb 7, 2023 — with giscus

那现在用什么了

MrZLeo Feb 7, 2023 — with giscus

@studymachiney 在文中这种情况下，可以直接写

static MUTEX: Mutex<i64> = Mutex::new(0);

Saltedf · 2022-12-03T05:01:55Z

Saltedf
Dec 3, 2022 — with giscus

CondVar 交替打印

    use std::sync::{Arc, Condvar, Mutex};
    use std::thread;

    #[derive(Clone, Debug)]
    enum Next {
        Child,
        Main,
    }

    let next = Arc::new(Mutex::new(Next::Main));
    let cond = Arc::new(Condvar::new());

    let next2 = next.clone();
    let cond2 = cond.clone();

    let handle = thread::spawn(move || {
        let mut lock = next2.lock().unwrap();
        let mut next_flag = (*lock).clone();
        drop(lock);

        for i in 1..=3 {
            while let Next::Main = next_flag {
                next_flag = (*cond2.wait(next2.lock().unwrap()).unwrap()).clone();
            } // next_flag 为 Next::Child 时跳出 while-loop
	    
	        eprintln!("child:\t{}", i);
	    
            next_flag= Next::Main;
	        *next2.lock().unwrap() = next_flag.clone();// 下一个进行打印的是main线程
        }
    });

    for i in 1..=3 {
	    eprintln!("main:\t{}", i);
	
        let mut next_flag = next.lock().unwrap();
        *next_flag = Next::Child; // 下一个进行打印的是child线程
	    drop(next_flag);
	
        cond.notify_one();
	    thread::sleep(Duration::from_secs(1));
	    //睡一秒, 给child线程提供上锁的机会. 
    }
    handle.join().unwrap();

输出:

main:	1
child:	1
main:	2
child:	2
main:	3
child:	3

2 replies

huangbqsky Dec 9, 2022 — with giscus

use lazy_static::lazy_static;
lazy_static! {
static ref MUTEX1: Mutex = Mutex::new(0);
static ref MUTEX2: Mutex = Mutex::new(0);
}

这段是什么意思，没看懂？运行报错

theCodedMike Mar 8, 2023 — with giscus

    let arc = Arc::new((Mutex::new(Next::Main), Condvar::new()));
    let arc_clone = Arc::clone(&arc);
    thread::spawn(move|| {
        let &(ref lock, ref cvar) = &*arc_clone;
        let mut guard = lock.lock().unwrap();
        for _ in 1..=10 {
            println!("child thread: 2");
            *guard = Next::Child;
            cvar.notify_one();
            while *guard == Next::Child {
                guard = cvar.wait(guard).unwrap();
            }
        }
    });
    let &(ref lock, ref cvar) = &*arc;
    let mut guard = lock.lock().unwrap();
    for _ in 1..=10 {
        println!(" main thread: 1");
        while *guard == Next::Main {
            guard = cvar.wait(guard).unwrap();
        }
        *guard = Next::Main;
        cvar.notify_one();
    }

这样也行

pycj · 2023-01-13T08:29:12Z

pycj
Jan 13, 2023 — with giscus

互斥锁是不是相当于数量为1的信号量

1 reply

leaf-potato Aug 20, 2024 — with giscus

可以这么理解~

Yhao90 · 2023-01-28T03:32:25Z

Yhao90
Jan 28, 2023 — with giscus

Condvar的这一块代码没大懂

{
                m = false;
                *cflag.lock().unwrap() = false;
}

*cflag.lock().unwrap() = false; 感觉不需要这一行，因为 m 已经是可变引用了，我再ide试了下结果也是正常的，有大神解答下吗

3 replies

tickscn Feb 19, 2023 — with giscus

m 不是引用，m 只是一个普通的 bool 值。ide 应该会提示你 m 的值类型的。

tickscn Feb 19, 2023 — with giscus

结果是正常的是因为现在只有主线程会去唤醒休眠的条件变量，去掉 cflag.lock().unwrap() = false; 如果还有其他线程会唤醒这个条件变量，执行结果就不符合预期了

while !m {
    m = *ccond.wait(cflag.lock().unwrap()).unwrap(); // 这一行因为没有被主线程唤醒所以也会阻塞住的，即使条件已经满足了
}

tickscn Feb 19, 2023 — with giscus

use std::sync::{Arc, Condvar, Mutex};
use std::thread::{sleep, spawn};
use std::time::Duration;

fn main() {
    let flag = Arc::new(Mutex::new(false));
    let cond = Arc::new(Condvar::new());
    let cflag = flag.clone();
    let ccond = cond.clone();

    let hdl = spawn(move || {
        let mut m = { *cflag.lock().unwrap() };
        let mut counter = 0;

        while counter < 3 {
            while !m {
                m = *ccond.wait(cflag.lock().unwrap()).unwrap();
            }

            {
                m = false;
                //  *cflag.lock().unwrap() = false;
            }

            counter += 1;
            println!("inner counter: {}", counter);
        }
    });

    // 下面加的代码就是定时去唤醒，如果注释掉 `*cflag.lock.unwarp() = false`, 就不能主线程和上面的线程交替输出了
    let ccond2 = cond.clone();
    _ = spawn(move || loop {
        sleep(Duration::from_millis(100));
        ccond2.notify_one();
    });


    let mut counter = 0;
    loop {
        sleep(Duration::from_millis(1000));
        {
            *flag.lock().unwrap() = true;
        }
        counter += 1;
        if counter > 3 {
            break;
        }
        println!("outside counter: {}", counter);
        cond.notify_one();
    }
    hdl.join().unwrap();
    println!("{:?}", flag);
}

vinland-avalon · 2023-01-30T09:15:03Z

vinland-avalon
Jan 30, 2023 — with giscus

请教下面的问题（注释中）：

let flag = Arc::new(Mutex::new(false));
let cond = Arc::new(Condvar::new());
let cflag = flag.clone();
let ccond = cond.clone();

let hdl = spawn(move || {
    let mut m = { *cflag.lock().unwrap() };    // 此时申请过Mutex
    let mut counter = 0;

    while counter < 3 {
        while !m {
            m = *ccond.wait(cflag.lock().unwrap()).unwrap();    //此时又申请一次Mutex （wait的参数），不会导致死锁吗
        }

        {
            m = false;
            *cflag.lock().unwrap() = false;
        }

        counter += 1;
        println!("inner counter: {}", counter);
    }
});

let mut counter = 0;
loop {
    sleep(Duration::from_millis(1000));
    *flag.lock().unwrap() = true;
    counter += 1;
    if counter > 3 {
        break;
    }
    println!("outside counter: {}", counter);
    cond.notify_one();
}
hdl.join().unwrap();
println!("{:?}", flag);

1 reply

tickscn Feb 19, 2023 — with giscus

let hdl = spawn(move || {
    let mut m = { *cflag.lock().unwrap() };    // 此时申请过Mutex。但是超出作用域了，这个 lock 的返回值自动 drop, 同时释放锁
    let mut counter = 0;

    while counter < 3 {
        while !m {
            m = *ccond.wait(cflag.lock().unwrap()).unwrap();    
        }

        {
            m = false;
            *cflag.lock().unwrap() = false;
        }

        counter += 1;
        println!("inner counter: {}", counter);
    }
});

studymachiney · 2023-02-07T07:46:01Z

studymachiney
Feb 7, 2023 — with giscus

多线程死锁加这个循环的代码for _ in 0..1是有什么用啊

0 replies

AiClvGu · 2023-07-17T03:09:15Z

AiClvGu
Jul 17, 2023 — with giscus

i wanna try unsafe concurrent progame but this result always be zero, I don't why :(

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
// let counter = Arc::new(Mutex::new(0));
let counter = Arc::new(Box::new(0));
let mut handles = vec![];

for _ in 0..10 {
    let counter = Arc::clone(&counter);
    let handle = thread::spawn(move || {
        let mut num = **counter;
        num += 1;
    });
    handles.push(handle);
}

for handle in handles {
    handle.join().unwrap();
}

// println!("Result: {}", *counter.lock().unwrap());
println!("Result: {}", *counter);

}

1 reply

lalala-233 Jun 16, 2024 — with giscus

let mut num = **counter;

These is a copy, not a reference. So you just change the value of num instead of counter.

You use Box instead of Mutex, but Arc don't support trait DerefMut, which meas you should use interior-mutability to change the value.

imsjkk · 2023-10-06T10:54:50Z

imsjkk
Oct 6, 2023 — with giscus

为什么condvar的例子中注释了sleep语句会程序运行错误？

0 replies

Bylx666 · 2023-10-07T01:16:25Z

Bylx666
Oct 7, 2023 — with giscus

condvar章节的while !*lock的!是啥东西

2 replies

Bylx666 Oct 7, 2023 — with giscus

呃呃我还以为是语法，其实只是switch bool用的吧

imsjkk Oct 7, 2023 — with giscus

就是判断lock内的值是false就循环，true就跳出循环吧

aq15951 · 2023-12-05T02:25:06Z

aq15951
Dec 5, 2023 — with giscus

用条件变量(Condvar)控制线程的同步，主线程这里获取了锁*flag.lock().unwrap()；子线程clone的变量又去获取锁c_flag.lock().unwrap(); 这里不是造成死锁吗，谁能解答一下

0 replies

LeeeeeeM · 2023-12-22T11:20:24Z

LeeeeeeM
Dec 22, 2023 — with giscus

安装依赖
tokio = { version = "1.35.1", features = ["full"] }

0 replies

suncunqian · 2024-04-18T17:44:33Z

suncunqian
Apr 18, 2024 — with giscus

condvar例子中为什么要这么写？

            while !*lock {
                lock = ccond.wait(lock).unwrap();
            }

我把代码修改为：去掉while循环，注释掉flag cflag的修改
效果一样

use std::sync::{Arc,Mutex,Condvar};
use std::thread::{spawn,sleep};
use std::time::Duration;

fn main() {
    let flag = Arc::new(Mutex::new(false));
    let cond = Arc::new(Condvar::new());
    let cflag = flag.clone();
    let ccond = cond.clone();

    let hdl = spawn(move || {
        let mut lock = cflag.lock().unwrap();
        let mut counter = 0;

        while counter < 3 {
                // wait方法会接收一个MutexGuard<'a, T>，且它会自动地暂时释放这个锁，使其他线程可以拿到锁并进行数据更新。
                // 同时当前线程在此处会被阻塞，直到被其他地方notify后，它会将原本的MutexGuard<'a, T>还给我们，即重新获取到了锁，同时唤醒了此线程。
                lock = ccond.wait(lock).unwrap();
            
            // *lock = false;

            counter += 1;
            println!("inner counter: {}", counter);
        }
    });

    let mut counter = 0;
    loop {
        sleep(Duration::from_millis(1000));
        // *flag.lock().unwrap() = true;
        counter += 1;
        if counter > 3 {
            break;
        }
        println!("outside counter: {}", counter);
        cond.notify_one();
    }
    hdl.join().unwrap();
    println!("{:?}", flag);
}

2 replies

suncunqian Apr 18, 2024 — with giscus

逻辑无非就是阻塞等信号阻塞等信号

lalala-233 Jun 15, 2024

.wait() 方法容易受虚假唤醒的影响。

Rust 文档中这么说：

Note that this function is susceptible to spurious wakeups. Condition variables normally have a boolean predicate associated with them, and the predicate must always be checked each time this function returns to protect against spurious wakeups.

因此还需要用 while 判断一下。

虚假唤醒（Spurious Wakeup）是一种在多线程编程中常见的问题。它发生在一个线程被意外地唤醒，而实际上并没有收到任何通知或信号。这种情况通常发生在线程等待某个条件满足时，但是在条件未满足的情况下也被唤醒。

虚假唤醒可能导致一些问题，例如线程在条件未满足时继续执行，或者线程在等待条件时被无限期地唤醒。为了避免这种情况，通常的做法是在等待条件时使用循环，而不是一次性地等待条件。这样，线程在被唤醒后可以再次检查条件是否满足，如果未满足则继续等待。

你或许可以试着 thread::spawn() 一个新的线程然后再把你修改后的代码放进去，说不定就能复现出虚假唤醒（我在 main 函数中没复现出来，但用一个线程发一个线程收就复现出来了）。

标准库里还有一个方法 .wait_while()，这个方法不受虚假唤醒的影响——它内部帮你完成了 while 循环的判断（

DrEden33773 · 2024-04-23T11:52:57Z

DrEden33773
Apr 23, 2024 — with giscus

温馨提示: 自从rust 1.7.0版本后, Semaphore 就被从标准库中移除了

0 replies

sixqa · 2024-06-11T10:27:14Z

sixqa
Jun 11, 2024 — with giscus

2024年6月，测试rust std sync 的rwlock与mutex锁与 spin 的自旋锁速度相当。

0 replies

W2Q3Q1 · 2024-09-30T03:06:51Z

W2Q3Q1
Sep 30, 2024 — with giscus

此处建议加一下虚假唤醒的教程，不然的话无法解释这段代码

while !*lock {
    // wait方法会接收一个MutexGuard<'a, T>，且它会自动地暂时释放这个锁，使其他线程可以拿到锁并进行数据更新。
    // 同时当前线程在此处会被阻塞，直到被其他地方notify后，它会将原本的MutexGuard<'a, T>还给我们，即重新获取到了锁，同时唤醒了此线程。
     lock = ccond.wait(lock).unwrap();
}

0 replies

Pro741 · 2024-11-04T01:43:57Z

Pro741
Nov 4, 2024 — with giscus

用条件变量(Condvar)控制线程的同步

这个例子感觉也不是很好啊, 想要正常输出, 主线程就必须休息阻塞一会:

sleep(Duration::from_millis(1000));

这个时间控制的太随意了吧, 控制时间短了影响子线程的运行, 主线程一直阻塞, 时间长了有影响性能

有没有大佬有其他解决办法呢?

0 replies

ADkun · 2024-11-05T06:35:04Z

ADkun
Nov 5, 2024 — with giscus

自己用Condvar和Mutex实现的一个信号量：

use std::sync::{Arc, Condvar, Mutex};

pub struct Semaphore {
    count: Mutex<u64>,
    cv: Condvar,
}

impl Semaphore {
    pub fn new(count: u64) -> Self {
        Self {
            count: Mutex::new(count),
            cv: Condvar::new(),
        }
    }

    pub fn arc(count: u64) -> Arc<Self> {
        Arc::new(Self::new(count))
    }

    pub fn acquire(&self) -> SemGuard {
        let mut guard = self
            .cv
            .wait_while(self.count.lock().unwrap(), |count| *count == 0)
            .unwrap();
        *guard -= 1;
        SemGuard { sem: self }
    }

    fn release(&self) {
        let mut guard = self.count.lock().unwrap();
        *guard += 1;
        self.cv.notify_one();
    }
}

pub struct SemGuard<'a> {
    sem: &'a Semaphore,
}

impl<'a> Drop for SemGuard<'a> {
    fn drop(&mut self) {
        self.sem.release();
    }
}

0 replies

ADkun · 2024-11-05T06:50:54Z

ADkun
Nov 5, 2024 — with giscus

用Mutex和Condvar实现的一个Barrier：

use std::sync::{Arc, Condvar, Mutex};

pub struct Barrier {
    count: Mutex<State>,
    cv: Condvar,
    total: u64,
}

struct State {
    count: u64,
    generation: u64,
}

impl Barrier {
    pub fn new(count: u64) -> Self {
        Self {
            count: Mutex::new(State {
                count,
                generation: 0,
            }),
            cv: Condvar::new(),
            total: count,
        }
    }

    pub fn arc(count: u64) -> Arc<Self> {
        Arc::new(Self::new(count))
    }

    pub fn wait(&self) {
        let mut state = self.count.lock().unwrap();
        let current_generation = state.generation;
        state.count -= 1;
        if state.count == 0 {
            state.count = self.total;
            state.generation += 1;
            self.cv.notify_all();
        } else {
            while current_generation == state.generation {
                state = self.cv.wait(state).unwrap();
            }
        }
    }
}

0 replies

cctga · 2024-12-17T08:53:48Z

cctga
Dec 17, 2024 — with giscus

标准库中的信号量不再推荐使用写了原因：总结起来是不是就是"信号量没什么卵用"

0 replies

advance/concurrency-with-threads/sync1 #736

giscus[bot] bot Apr 6, 2022

advance/concurrency-with-threads/sync1

Replies: 25 comments · 29 replies

siu91 Apr 14, 2022 — with giscus

qian6block Dec 2, 2024 — with giscus

siu91 Apr 15, 2022 — with giscus

aardwolfchen Feb 20, 2023 — with giscus

aardwolfchen Feb 20, 2023 — with giscus

Linuxdazhao Mar 1, 2023 — with giscus

masayil May 15, 2023

ANIDENTIFIER Jun 17, 2023 — with giscus

aresbit Apr 17, 2022 — with giscus

mxismean Apr 18, 2022 — with giscus

aly8246 Jul 11, 2022 — with giscus

aly8246 Jul 11, 2022 — with giscus

ttsy1995 May 11, 2023 — with giscus

licq Jul 21, 2022 — with giscus

W2Q3Q1 Sep 30, 2024 — with giscus

zhouhaoan Aug 14, 2022 — with giscus

Aresona Aug 18, 2022 — with giscus

MrZLeo Aug 30, 2022 — with giscus

studymachiney Feb 7, 2023 — with giscus

MrZLeo Feb 7, 2023 — with giscus

Saltedf Dec 3, 2022 — with giscus

huangbqsky Dec 9, 2022 — with giscus

theCodedMike Mar 8, 2023 — with giscus

pycj Jan 13, 2023 — with giscus

leaf-potato Aug 20, 2024 — with giscus

Yhao90 Jan 28, 2023 — with giscus

tickscn Feb 19, 2023 — with giscus

tickscn Feb 19, 2023 — with giscus

tickscn Feb 19, 2023 — with giscus

vinland-avalon Jan 30, 2023 — with giscus

tickscn Feb 19, 2023 — with giscus

studymachiney Feb 7, 2023 — with giscus

AiClvGu Jul 17, 2023 — with giscus

lalala-233 Jun 16, 2024 — with giscus

imsjkk Oct 6, 2023 — with giscus

Bylx666 Oct 7, 2023 — with giscus

Bylx666 Oct 7, 2023 — with giscus

imsjkk Oct 7, 2023 — with giscus

aq15951 Dec 5, 2023 — with giscus

LeeeeeeM Dec 22, 2023 — with giscus

suncunqian Apr 18, 2024 — with giscus

suncunqian Apr 18, 2024 — with giscus

lalala-233 Jun 15, 2024

DrEden33773 Apr 23, 2024 — with giscus

sixqa Jun 11, 2024 — with giscus

W2Q3Q1 Sep 30, 2024 — with giscus

Pro741 Nov 4, 2024 — with giscus

ADkun Nov 5, 2024 — with giscus

ADkun Nov 5, 2024 — with giscus

cctga Dec 17, 2024 — with giscus

giscus[bot]
bot Apr 6, 2022

Replies: 25 comments 29 replies

siu91
Apr 14, 2022 — with giscus

siu91
Apr 15, 2022 — with giscus

aresbit
Apr 17, 2022 — with giscus

mxismean
Apr 18, 2022 — with giscus

licq
Jul 21, 2022 — with giscus

zhouhaoan
Aug 14, 2022 — with giscus

MrZLeo
Aug 30, 2022 — with giscus

Saltedf
Dec 3, 2022 — with giscus

pycj
Jan 13, 2023 — with giscus

Yhao90
Jan 28, 2023 — with giscus

vinland-avalon
Jan 30, 2023 — with giscus

studymachiney
Feb 7, 2023 — with giscus

AiClvGu
Jul 17, 2023 — with giscus

imsjkk
Oct 6, 2023 — with giscus

Bylx666
Oct 7, 2023 — with giscus

aq15951
Dec 5, 2023 — with giscus

LeeeeeeM
Dec 22, 2023 — with giscus

suncunqian
Apr 18, 2024 — with giscus

DrEden33773
Apr 23, 2024 — with giscus

sixqa
Jun 11, 2024 — with giscus

W2Q3Q1
Sep 30, 2024 — with giscus

Pro741
Nov 4, 2024 — with giscus

ADkun
Nov 5, 2024 — with giscus

ADkun
Nov 5, 2024 — with giscus

cctga
Dec 17, 2024 — with giscus