我有一个程序,它对于 linuxthreads 和 nptl 的工作方式必须不同。
这个库中是否有定义,可以在我的程序中使用来检测,是使用 nptl 还是使用 linuxthreads?
UPDATE1:对于运行时有一个getconf GLIBC_LIBPTHREADS,但是对于编译时呢?
我有一个程序,它对于 linuxthreads 和 nptl 的工作方式必须不同。
这个库中是否有定义,可以在我的程序中使用来检测,是使用 nptl 还是使用 linuxthreads?
UPDATE1:对于运行时有一个getconf GLIBC_LIBPTHREADS,但是对于编译时呢?
看起来这不可能,您可以在加载时更改实现,因此无论您做什么,都无法在编译时知道。
从 pthreads 手册页:
在具有同时支持 LinuxThreads 和 NPTL(即 glibc 2.3.x)的 glibc 的系统上,LD_ASSUME_KERNEL 环境变量可用于覆盖动态链接器的线程实现的默认选择。这个变量告诉动态链接器假设它运行在一个特定的内核版本之上。通过指定不提供 NPTL 所需支持的内核版本,我们可以强制使用 LinuxThreads。(这样做的最可能的原因是运行一个(损坏的)应用程序,该应用程序依赖于 LinuxThreads 中的一些不合格行为。)例如:
bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \ awk '{print $3}' ) | egrep -i 'threads|ntpl' linuxthreads-0.10 by Xavier Leroy
更不用说这两个实现(大部分)是二进制兼容的,所以基本上你在编译时永远不知道将使用哪个线程库,因为它可能会根据程序运行时存在的环境变量而改变,或者有人可以将二进制文件从 NPTL 系统复制到 LinuxThreads 系统。你只是不能这样做,因为它不是在编译时已知的东西,至少不是你可以依赖的方式。
您必须找到某种方法来使用运行时检测,或者您可以使用有关您为什么要这样做的信息来更新您的帖子,并且有人可能会提供有关如何以其他方式完成它或如何实现它的建议可以使用运行时检测哪些 pthread 正在使用中。
另一种可能的解决方案是在您的配置脚本中添加一个选项,并让编译它的人选择。
让我们退后一步问一下——你为什么要这样做?
是否有一个人提供而另一个人没有的功能?如果是这样,也许您可以使用dlsym
onlibpthread.so
在运行时动态查询它们的存在。
还是它们之间的某些行为不同,导致您的程序行为不端?如果是这样,我会避免依赖此类行为的结果,或者参考像 POSIX 这样的标准来确定你可以依赖什么。通常,此类可移植性错误代表代码中的真正缺陷,即使使用您认为“有效”的库,也可能需要解决这些缺陷。当并发进入图片时,正确处理尤其重要。
最后,如果是结构大小的问题......也可能有一些hacky方法。例如(只是一个例子,可能完全偏离基础,但说明了这个想法):
// Hack around difference in pthread_mutex_t
//
#define pthread_mutex_t pthread_mutex_t_linuxthreads
#include <some_linuxthreads_header.h>
#undef pthread_mutex_t
#define pthread_mutex_t pthread_mutex_t_ntpl
#include <some_ntpl_header.h>
#undef pthread_mutex_t
typedef union {
pthread_mutex_t_linxthreads linuxthreads;
pthread_mutex_t_ntpl ntpl;
} pthread_mutex_t;
非常hacky和非常丑陋,但只是将这些想法作为一种可能的解决方法扔在那里......
查看标题后,没有 - 没有针对 NPTL 与 LinuxThreads 的具体定义。
如果您需要这样的定义,请编写一个生成头文件的小脚本,或将定义标志传递给编译器。您可以通过解析 /lib/libc.so.6 的输出来获取信息(该库可以作为普通可执行文件直接运行)。我会把细节留给你,但输出看起来像:
Linux线程:
GNU C 库稳定版本 2.3.4,由 Roland McGrath 等人编写。 版权所有 (C) 2005 Free Software Foundation, Inc. 这是免费软件;查看复制条件的来源。 没有保修;甚至不适合适销性或适合性 特殊用途。 由 GNU CC 版本 3.4.6 20060404 (Red Hat 3.4.6-11) 编译。 于 2010 年 4 月 18 日在 Linux 2.4.20 系统上编译。 可用的扩展: Per Bothner 的 GNU libio Michael Glad 和其他人的 crypt 附加组件 2.1 版 Xavier Leroy 的 linuxthreads-0.10 C 存根插件版本 2.1.2。 BIND-8.2.3-T5B NIS(YP)/NIS+ NSS 模块 0.19,作者 Thorsten Kukuk Cristian Gafton 的 Glibc-2.0 兼容性插件 Simon Josefsson 的 GNU Libidn Alpha Processor Inc 赞助的 libthread_db 工作 包括线程本地存储支持。 有关错误报告说明,请参阅: .
NPTL:
GNU C 库稳定版 2.5,由 Roland McGrath 等人编写。 版权所有 (C) 2006 Free Software Foundation, Inc. 这是免费软件;查看复制条件的来源。 没有保修;甚至不适合适销性或适合性 特殊用途。 由 GNU CC 版本 4.1.2 20080704 (Red Hat 4.1.2-48) 编译。 于 2010 年 10 月 25 日在 Linux 2.6.9 系统上编译。 可用的扩展: C 存根插件版本 2.1.2。 Michael Glad 和其他人的 crypt 附加组件 2.1 版 Simon Josefsson 的 GNU Libidn Per Bothner 的 GNU libio NIS(YP)/NIS+ NSS 模块 0.19,作者 Thorsten Kukuk Ulrich Drepper 等人的本机 POSIX 线程库 BIND-8.2.3-T5B RT使用linux内核aio 包括线程本地存储支持。 有关错误报告说明,请参阅: .
(尽管,尝试编写不需要处理此问题的代码。到目前为止,我们在 RHEL 4(linuxthreads)和 RHEL 5(NPTL)上运行的多线程应用程序中还没有遇到任何需要)