linux - 在 Linux 中实现快速 "GetCurrentThreadId"

Question

Windows NT 有一个很好的函数叫做GetCurrentThreadId顾名思义。它的实现非常快，因为它只是从线程本地存储中读取一个变量，该变量是在 NT 内核创建线程期间写入的。我想在 Linux 中实现它，但遇到了麻烦。

我最初的实现是这样的:

typedef pid_t ThreadID;

ThreadID GetCurrentThreadId(void)
{
    static __thread ThreadID t_cachedID = (ThreadID) -1;

    if (__builtin_expect(t_cachedID == (ThreadID) -1, 0))
    {
        t_cachedID = (ThreadID) syscall(__NR_gettid);
    }

    return t_cachedID;
}

问题是fork .在使用 fork 的程序中, t_cachedID变得陈旧 - 新子进程的主线程有一份调用 fork 的线程的本地线程存储副本，那t_cachedID不再正确。

解决方案应该是 pthread_atfork , 从而改变 t_cachedID新子进程中的值设置为 -1，但作为 Pthreads API 的规范，它的设计很糟糕。如果您是使用 dlclose 卸载的 DLL , pthread_atfork不知道这一点，并且仍会尝试在 fork 上调用您的函数, 和 kaboom。糟糕的设计决策#1。也没有用于删除回调函数的 API。糟糕的设计决策 #2。

有一个模糊记录的 glibc 函数，名为 __register_atfork这似乎是为解决这个问题而设计的，但它需要一个 DLL 句柄而不是提供一种方法来删除你的 *_atfork处理程序。在尝试解决 POSIX 糟糕的设计决策时，glibc 的第一个糟糕设计决策。

如何获得自己的 DLL 句柄？在 Linux 中，它看起来像 dlopen返回不同的 void *处理每次有人调用 dlopen在 DLL/.so 文件上，而不是仅仅维护一个引用计数......？它不像 Windows，其中 DLL 句柄等于节映射的基地址。除非有一些简单的方法可以在 Linux 中获取您自己的 DLL 句柄，否则这会导致错误的设计决策 #2。

有没有更好、更合适的方法来做到这一点？

Answer 1

嗯，实际上 posix 已经 contains function返回线程 ID:

 pthread_self() //thanks to alk 

旧答案:<罢工>

<罢工>

int thr_self()

<罢工>