condition_variable的怪事

最新推荐文章于 2023-05-30 17:01:55 发布

weixin_34354173

最新推荐文章于 2023-05-30 17:01:55 发布

阅读量94

点赞数

文章标签： python xcode

原文链接：https://my.oschina.net/u/1864567/blog/342162

版权

2019独角兽企业重金招聘Python工程师标准>>>

今天看了篇介绍condition_variable的文章。于是copy例子到IDE下运行看看，小改了个地方，就出现了让我百思不得姐的结果。程序如下：

#include <iostream>                // std::cout
#include <thread>                // std::thread
#include <mutex>                // std::mutex, std::unique_lock
#include <condition_variable>    // std::condition_variable

std::mutex mtx; // 全局互斥锁.
std::condition_variable cv; // 全局条件变量.
bool ready = false; // 全局标志位.

void do_print_id(int id)
{
    int local = id;
    std::unique_lock <std::mutex> lck(mtx);
    while (!ready) {// 如果标志位不为 true, 则等待...
        cv.wait(lck); // 当前线程被阻塞, 当全局标志位变为 true 之后,
        local++; //这句到底执行还是不执行？
    }
    // 线程被唤醒, 继续往下执行打印线程编号id.
    std::cout << "thread " << id << "\tlocal " << local << std::endl;
}

void go()
{
    std::unique_lock <std::mutex> lck(mtx);
    ready = true; // 设置全局标志位为 true.
    cv.notify_all(); // 唤醒所有线程.
    std::cout << "notify_all\n";
}

int main()
{
    const int threads_num = 5; //改变此常数，结果就发生变化了～
    std::thread threads[threads_num];
    // spawn 10 threads:
    for (int i = 0; i < threads_num; ++i)
        threads[i] = std::thread(do_print_id, i);
    
    std::cout << "10 threads ready to race...\n";
    go(); // go!
    
    for (auto & th:threads)
        th.join();
    
    return 0;
}

上述程序中，改变线程数，即
const int threads_num = 5;
结果就发生变化了～当threads_num<=5时结果如下：

10 threads ready to race... notify_all thread 4 local 4 thread 1 local 2 thread 0 local 0 thread 2 local 2 thread 3 local 3

当threads_num>=10，大部分时候程序运行结果如下：

10 threads ready to race... notify_all thread 5 local 6 thread 0 local 1 thread 3 local 4 thread 2 local 3 thread 1 local 2 thread 7 local 8 thread 4 local 5 thread 6 local 7 thread 8 local 9 thread 9 local 10

当threads_num介于5和10之间时，结果在两者之间。

基本上就是当线程数较小时， cv.wait(lck);后面的那句local++; 不执行；当线程数较大时，又执行了…… 按道理来讲，cv.wait(lck);之后线程阻塞，那么当cv.notify_all();唤醒所有线程之后应该从阻塞的地方开始继续执行才对，就应该每次都会执行后面的local++; 为何程序行为会不一致呢？

程序的运行环境是Xcode6.1。系统默认编译器。

哪位大神帮忙看一下是什么原因？

——————————————————后续的分割线———————————————————— 多谢 @BrotherClose 的点拨。通过这个还有几个发现：

其实第一个const int threads_num = 5时，我贴出来的运行结果仔细看，会发现第二行： thread 1 local 2 已经开始加一了。而我没仔细看，还以为全都是相等的…… 如果看出来这个细微的区别的话，也可能会发现线索，找出原因。
程序有改进的空间，不将local用id来赋值，而是初始值为0，那么结果只有1和0两个种，一目了然，而不必比对是否加一。完全是庸人自扰，自寻烦恼啊。
为何当启动线程数量较小时主线程相对优先级较高？而线程数较大时主线程优先级变低？是否和处理器的数量有关呢？主线程也子线程权重差不多，要在多个核心上重新分配，这样第一次分配到主线程的机会就少了？后来测试，发现cout可能涉及IO操作，会拖慢线程执行，当某线程cout还没完成时，其他线程又获得了时间片来执行，结果就反超了。将程序中的log作用的cout都注释掉，发现当 const int threads_num = 10时，打印结果里相等的还占大多数，可见cout的影响还是蛮大的。

转载于:https://my.oschina.net/u/1864567/blog/342162