1

我正在试验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"

我遇到了一些有趣的不一致之处。如果我设置了一个long ，比如1秒NAP_DURATION（几毫秒。1000000121NAP_DURATION

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

因此，对于问题：

  1. 这是预期的行为吗？
  2. 有没有办法控制这种行为，例如使作用域锁表现得像锁定操作排队？
  3. 如果 (2) 的答案是“否”，是否可以使用Boost条件变量实现类似的效果，而不必担心锁定/解锁调用失败？
  4. scoped_locks保证解锁吗？我正在使用 RAII 方法而不是手动锁定/解锁，因为显然解锁操作可能会失败并引发异常，我正在尝试使此代码可靠。

谢谢你。

澄清

我知道将调用线程置于睡眠状态不会解锁互斥锁，因为它仍在范围内，但预期的调度是：

  • Thread1 锁定，获取互斥锁。
  • Thread2 锁定、阻塞。
  • Thread1 执行，释放锁定，并立即尝试再次锁定。
  • Thread2 已经在等待锁，在 thread1 之前得到它。
4

2 回答 2

5

这是预期的行为吗？

是和不是。您不应该对哪个线程将获得互斥锁抱有任何期望，因为它是未指定的。但这肯定在预期行为的范围内。

有没有办法控制这种行为，例如使作用域锁表现得像锁定操作排队？

不要以这种方式使用互斥锁。只是不要。仅使用互斥锁，以便它们相对于线程正在执行的其他事情保持非常短的时间。

如果 (2) 的答案是“否”，是否可以使用 Boost 条件变量实现类似的效果，而不必担心锁定/解锁调用失败？

当然。编码你想要的。

scoped_locks 是否保证解锁？我正在使用 RAII 方法而不是手动锁定/解锁，因为显然解锁操作可能会失败并引发异常，我正在尝试使此代码可靠。

目前尚不清楚您担心的是什么，但建议使用 RAII 方法。

于 2015-06-23T17:00:33.643 回答
1

你为什么感到惊讶，究竟是什么？如果您希望线程 2 在线程 1 处于睡眠状态时获取互斥锁，那么，是的，这是预期行为并且您的理解是错误的，因为您的锁在范围内。

但是，如果您因为循环迭代结束时线程 1 和线程 2 之间缺乏交替而感到惊讶，那么您可以看看这个关于调度的 SO question似乎“不公平”

于 2015-06-23T16:28:22.733 回答