当前位置： 文江博客话题详情

linuxthreads 和 nptl 有具体定义吗

发布于 2024-09-14 17:29:10 字数 174 浏览 3 评论 0原文

我有一个程序，对于 linuxthreads 和 nptl 来说，它的工作方式必须不同。

这个库中是否有定义，可以在我的程序中使用来检测，是使用 nptl 还是使用 linuxthreads？

UPDATE1：对于运行时，有一个 getconf GLIBC_LIBPTHREADS，但是对于编译时呢？

原文

I hav a programme, which must work differently for linuxthreads and nptl.

Are there defines in this libs, that can be used in my programme to detect, is nptl is used or is linuxthreads is?

UPDATE1: For runtime there is a getconf GLIBC_LIBPTHREADS, but what for compile-time?

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（3）

黑色毁心梦 2024-09-21 17:29:10

看起来这是不可能的，您可以在加载时更改实现，因此无论您做什么，都无法在编译时知道。

来自 pthreads 手册页：

在具有支持 glibc 的系统上
LinuxThreads 和 NPTL（即
glibc 2.3.x), LD_ASSUME_KERNEL
环境变量可用于
覆盖动态链接器的默认值
线程实现的选择。
这个变量告诉动态链接器
假设它运行在
特定的内核版本。经过
指定一个内核版本
不提供所需的支持
NPTL，我们可以强制使用
Linux 线程。 （最有可能的原因
这样做的方法是运行一个（损坏的）
依赖于某些应用程序
中的不合格行为
LinuxThreads。）例如：

bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
                awk '{print $3}' ) | egrep -i '线程|ntpl'
linuxthreads-0.10，作者：Xavier Leroy

更不用说这两种实现（大部分）是二进制兼容的，所以基本上你无法在编译时知道将使用哪个线程库，因为它可能会根据程序运行时存在的环境变量而改变运行，或者有人可以将二进制文件从 NPTL 系统复制到 LinuxThreads 系统。你就是做不到，因为它不是编译时已知的东西，至少不是你可以依赖的方式。

您必须找到某种方法来使用运行时检测，或者也许您可以使用有关为什么要执行此操作的信息来更新您的帖子，并且有人可能会提供有关如何以其他方式完成它或如何实现它的建议可以使用运行时检测正在使用哪些 pthread。

另一种可能的解决方案是向配置脚本添加一个选项，并让编译它的人进行选择。

Doesn't look like this is possible, you can change the implementation at load time so there's no way to know at compile time no matter what you do.

from the pthreads man page:

On systems with a glibc that supports
both LinuxThreads and NPTL (i.e.,
glibc 2.3.x), the LD_ASSUME_KERNEL
environment variable can be used to
override the dynamic linker's default
choice of threading implementation.
This variable tells the dynamic linker
to assume that it is running on top of
a particular kernel version. By
specifying a kernel version that does
not provide the support required by
NPTL, we can force the use of
LinuxThreads. (The most likely reason
for doing this is to run a (broken)
application that depends on some
nonconformant behavior in
LinuxThreads.) For example:

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

Not to mention that the two implementations are (mostly) binary compatible, so basically you CANNOT know at compile time which thread library will be used, EVER, because it might change depending on the environment variables present when your program is run, or someone could copy the binary from an NPTL system to a LinuxThreads system. You just can't do it, because it's not something that is known at compile time, at least not in a way you can rely on.

You'll have to find some way to use run time detection, or maybe you could update your post with information about WHY you want to do this and someone could maybe offer advice about how to accomplish it some other way, or how to make it possible to use run time detection of which pthreads is in use.

The other possible solution is to add an option to your configure script and make the person compiling it choose.

回复 原文
素染倾城色 2024-09-21 17:29:10

让我们退一步问——你为什么要这样做？

是否存在一种功能是一种功能而另一种功能则没有的？如果是这样，也许你可以在 libpthread 上使用 dlsym .so 在运行时动态查询它们的存在。

或者更多的是它们之间的某些行为不同，导致您的程序行为不当？如果是这样，我会避免依赖此类行为的结果，或者参考 POSIX 等标准来确定您可以依赖什么。通常，此类可移植性错误代表了代码中的真正缺陷，即使使用您认为正在“工作”的库，也可能需要解决这些缺陷。当并发出现时，正确处理这一点尤为重要。

最后，如果是结构大小的问题......也可能有一些奇怪的方法来解决这个问题。例如（只是一个例子，可能完全偏离基础，但说明了这个想法）：

// 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和非常丑陋，但只是将这些想法作为可能的解决方法扔在那里......

Let's take a step back and ask - why do you want to do this?

Are there functions that one provides that another does not? If so perhaps you can use dlsym on libpthread.so to dynamically query their existence at runtime.

Or is it more a matter of some behavior that differs between them, causing your program to misbehave? If so, I would avoid relying on the outcome of such behaviors, or consult a standard like POSIX to determine what you can rely on. Often such portability bugs represent real flaws in your code that might need addressing even using the library you think is "working". When concurrency enters the picture this is especially important to get right.

Lastly, if it's a matter of the sizes of structures... There may be hacky ways around this too. For example (just an example, may be totally off-base, but illustrates the idea):

// 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;

Very hacky and very ugly, but just throwing these kinds of ideas out there as a possible workaround...

回复 原文
拿命拼未来 2024-09-21 17:29:10

查看标题后，没有 - NPTL 与 LinuxThreads 没有具体的定义。

如果您需要这样的定义，请编写一个生成头文件的小脚本，或将定义标志传递给编译器。您可以通过解析 /lib/libc.so.6 的输出来获取信息（该库可以作为普通可执行文件直接运行）。我将把细节留给你，但输出看起来像：

LinuxThreads:

GNU C Library stable release version 2.3.4, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6 20060404 (Red Hat 3.4.6-11).
Compiled on a Linux 2.4.20 system on 2010-04-18.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        The C stubs add-on version 2.1.2.
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton
        GNU Libidn by Simon Josefsson
        libthread_db work sponsored by Alpha Processor Inc
Thread-local storage support included.
For bug reporting instructions, please see:
.

NPTL:

GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-48).
Compiled on a Linux 2.6.9 system on 2010-10-25.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
.

（不过，尝试编写不需要处理这个问题的代码。到目前为止，我们还没有遇到任何需要这样做的情况）我们在 RHEL 4（linuxthreads）与 RHEL 5（NPTL）上运行的多线程应用程序

After looking through the headers, no - there are no specific defines for NPTL vs LinuxThreads.

If you need such a define, write a little script that produces a header file, or pass a define flag to the compiler. You can get the info by parsing the output of /lib/libc.so.6 (that library can be run direcly as a normal executable). I'll leave the details to you, but the output looks like:

LinuxThreads:

GNU C Library stable release version 2.3.4, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 3.4.6 20060404 (Red Hat 3.4.6-11).
Compiled on a Linux 2.4.20 system on 2010-04-18.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        The C stubs add-on version 2.1.2.
        BIND-8.2.3-T5B
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Glibc-2.0 compatibility add-on by Cristian Gafton
        GNU Libidn by Simon Josefsson
        libthread_db work sponsored by Alpha Processor Inc
Thread-local storage support included.
For bug reporting instructions, please see:
.

NPTL:

GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-48).
Compiled on a Linux 2.6.9 system on 2010-10-25.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
.

(though, try to rather write code that doesn't need to deal with this. So far, we've not encountered any need for this in our multithreaded apps that run on RHEL 4(linuxthreads) vs RHEL 5(NPTL))

回复 原文
~没有更多了~

关于作者

白云悠悠

暂无简介

0 文章
0 评论
24 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

1CH1MKgiKxn9p

文章 0 评论 0

ゞ记忆︶ㄣ

文章 0 评论 0

JackDx

文章 0 评论 0

信远

文章 0 评论 0

yaoduoduo1995

文章 0 评论 0

霞映澄塘

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文