Are there specific defines of linuxthreads and nptl

Question

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?

Answer 1

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 (ie, 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.

Answer 2

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...

Answer 3

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))