condition_variable的怪事

今天看了篇介绍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 的点拨。经过这个还有几个发现：

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