Question

这曾经很好地工作（然后外星人必须攻击我的电脑）：

#include <thread>
#include <iostream>

int main()
{
    std::cout << std::this_thread::get_id() << std::endl;

    return 0;
}

现在打印thread::id of a non-executing thread。

ideone.com会打印一些ID，但有趣的是可能导致我的平台出现此行为。

$ uname -a
Linux xxx 3.13.0-77-generic #121-Ubuntu SMP Wed Jan 20 10:50:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

有什么想法吗？

编辑：嗯..当我添加

std::cout << pthread_self() << std::endl;

两行行打印相同的ID，但当我删除它时，结果仍然相同 - “非执行线程”。

Answer 1

这是glibc功能的副作用，修复于https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57060：

// For the GNU C library pthread_self() is usable without linking to
// libpthread.so but returns 0, so we cannot use it in single-threaded
// programs, because this_thread::get_id() != thread::id{} must be true.

如果您明确链接到pthreads（-pthread或-lpthread），那么您的程序将按预期运行。

奇怪的是，在我的系统上，添加对pthread_self的调用（在调用std::this_thread::get_id()之前或之后）不会改变行为：

0
thread::id of a non-executing thread

这可能是特定于Ubuntu的行为，如果调用pthread_self则自动链接pthreads，但它看起来有点奇怪。请注意std::this_thread::get_id()通过弱引用（本身通过pthread_self）调用__gthread_self。

Answer 2

标准实际上并未定义this_thread::get_id将返回的内容。它只是说：

返回：类型为thread :: id的对象，唯一标识当前的执行线程。没有其他执行线程可以拥有这个id和这个执行线程总是有这个id 。该返回的对象不应该等于默认构造螺纹:: ID。

这个条件符合你的输出，所以一切都井然有序。

顺便说一句，不要将thread_id返回的this_thread::get_id与std::thread::get_id()返回的数字线程ID混淆。 thread_id主要用法是在关联容器中进行比较和使用，而不是直接内省或打印。

打印std :: this_thread :: get_id（）给出“非执行线程的thread :: id”？

2 个答案: