用C++提升 - 好奇的互斥行为

Question

我正在尝试Boost线程,因为据我所知,我可以编写一个多线程Boost应用程序并在Windows或Linux中编译它,而pthreads我更熟悉的是,它严格用于*NIX系统.

我有以下示例应用程序,它是从另一个SO问题中借用的:

---

#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/bind.hpp>
#include <iostream>

#define NAP_DURATION    (10000UL)   // 10ms

boost::mutex io_mutex;

void count(int id)
{
    for (int i = 0; i < 1000; ++i)
    {
        boost::mutex::scoped_lock lock(io_mutex);
        std::cout << "Thread ID:" << id << ": " << i << std::endl;
        if (id == 1)
        {
            std::cout << "I'm thread " << id << " and I'm taking a short nap" << std::endl;
            usleep(NAP_DURATION);
        }
        else
        {
            std::cout << "I'm thread " << id << ", I drink 100 cups of coffee and don't need a nap" << std::endl;
        }
        std::cout << "Thread ID:" << id << ": " << i << std::endl;
        boost::thread::yield();
    }
}

int main(int argc, char* argv[])
{
    boost::thread thrd1( boost::bind(&count, 1));
    boost::thread thrd2( boost::bind(&count, 2));

    thrd1.join();
    thrd2.join();
    return 0;
}

---

我通过以下方式在我的Ubuntu 14.04 LTS系统上安装了Boost:

sudo apt-get install libboost-all-dev

我通过以下方式编译上面的代码:

g++ test.cpp -lboost_system -lboost_thread -I"$BOOST_INLCUDE" -L"$BOOST_LIB"

我遇到了似乎有些有趣的不一致之处.如果我设置了一个冗长的NAP_DURATION,比如说1秒(1000000),似乎只有线程才能1获得互斥锁,直到它完成其操作,并且线程2在线程1完成之前很少得到锁定,即使我将其NAP_DURATION设置为只是一个几毫秒.

当我使用类似的这样的应用程序编写时pthreads,锁通常会在线程之间或多或少地随机交替,因为另一个线程已经在互斥锁上被阻塞.

---

那么,问题是:

1. 这是预期的行为吗？
2. 有没有办法控制这种行为,比如使得作用域锁定的行为就像锁定操作排队一样？
3. 如果(2)的答案是"否",是否可以实现与Boost条件变量类似的东西而不必担心锁定/解锁呼叫失败？
4. 是scoped_locks的保证解锁？我正在使用RAII方法而不是手动锁定/解锁,因为显然解锁操作可能会失败并抛出异常,我正在尝试使此代码稳固.

谢谢.

澄清

我知道将调用线程置于休眠状态不会解锁互斥锁,因为它仍在范围内,但预期的调度顺序如下:

• Thread1锁定,获取互斥锁.
• Thread2锁,块.
• Thread1执行,释放锁,并立即再次尝试锁定.
• Thread2已经在等待锁定,在thread1之前获取它.

Answer 1

这是预期的行为吗？

是的,不是.您不应该对哪个线程获取互斥锁有任何期望,因为它未指定.但它肯定在预期的行为范围内.

有没有办法控制这种行为,比如使得作用域锁定的行为就像锁定操作排队一样？

不要以这种方式使用互斥锁.只是不要.仅使用互斥锁,使其相对于线程正在执行的其他操作保持非常短的时间段.

如果(2)的答案是"否",是否可以实现与Boost条件变量类似的东西,而不必担心锁定/解锁调用失败？

当然.编码你想要的.

scoped_locks保证解锁吗？我正在使用RAII方法而不是手动锁定/解锁,因为显然解锁操作可能会失败并抛出异常,我正在尝试使此代码稳固.

目前尚不清楚你担心的是什么,但建议使用RAII方法.