Ci sono definisce specifiche di linuxthreads e nptl

Question

I hav un programma, che deve lavorare in modo diverso per linuxthreads e nptl.

Ci sono definisce in questo librerie, che può essere utilizzato nel mio programma per rilevare, viene nptl viene utilizzato o è linuxthreads è?

Update1:? Per runtime c'è un GLIBC_LIBPTHREADS getconf, ma quello che per tempo di compilazione

Answer 1

Non sembra che questo è possibile, è possibile modificare l'implementazione in fase di carico in modo non c'è modo di sapere al momento della compilazione, non importa quello che fai.

dalla pagina pthreads man:

  

Su sistemi con una glibc che supporti   sia LinuxThreads e NPTL (cioè,   glibc 2.3.x), il LD_ASSUME_KERNEL   variabile ambiente può essere utilizzato per   ignorare predefinito del linker dinamico   scelta di implementazione filettatura.   Questa variabile dice al linker dinamico   supporre che è in esecuzione in cima   una particolare versione del kernel. Di   specificando una versione del kernel che fa   non fornire il supporto richiesto dalla   NPTL, siamo in grado di forzare l'uso di   LinuxThreads. (La probabile ragione più   per fare questo è quello di eseguire un (rotto)   applicazione che dipende da alcuni   comportamento nonconformant in   LinuxThreads). Ad esempio:

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

Senza contare che le due implementazioni sono (soprattutto) compatibile a livello binario, in modo sostanzialmente non è possibile sapere al momento della compilazione cui verrà utilizzato libreria di thread, MAI, perché potrebbe cambiare a seconda dell'ambiente variabili presentano quando il programma viene eseguito, o qualcuno potrebbe copiare il binario da un sistema di NPTL ad un sistema LinuxThreads. Non ci si può farlo, perché non è qualcosa che è noto al momento della compilazione, almeno non in un modo che può fare affidamento su.

Si dovrà trovare un modo per utilizzare il rilevamento fase di esecuzione, o forse si potrebbe aggiornare il tuo post con informazioni sul perché si vuole fare questo e qualcuno potrebbe forse offrire consigli su come realizzarlo in qualche altro modo, o come per rendere possibile utilizzare il rilevamento tempo di esecuzione di cui pthreads è in uso.

L'altra soluzione possibile è quella di aggiungere un'opzione per il vostro script di configurazione e rendere la persona compilarlo scegliere.

Answer 2

Facciamo un passo indietro e chiedere - perché si vuole fare questo

Vi sono funzioni che uno prevede che un altro no? Se è così, forse è possibile utilizzare dlsym su libpthread.so per interrogare dinamicamente la loro esistenza in fase di esecuzione.

O è più una questione di alcuni comportamenti che si differenzia tra di loro, causando il vostro programma a comportarsi male? Se è così, vorrei evitare di fare affidamento sul risultato di tali comportamenti, o consultare uno standard come POSIX per determinare ciò che si possono su cui contare. Spesso tali bug portabilità rappresentano difetti reali in codice che potrebbe essere necessario affrontare anche utilizzando la libreria pensate sta "lavorando". Quando la concorrenza entra in scena questo è particolarmente importante per ottenere di destra.

Infine, se si tratta di una questione di dimensioni delle strutture ... Ci possono essere modi hacky in tutto questo. Per esempio (solo un esempio, può essere totalmente off-base, ma illustra l'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;

Molto hacky e molto brutto, ma solo buttare questi tipi di idee là fuori come una possibile soluzione ...

Answer 3

Dopo aver guardato attraverso le intestazioni, no - non ci sono definisce specifici per NPTL vs LinuxThreads

.

Se avete bisogno di un tale definire, scrivere un piccolo script che produce un file di intestazione, o passare un definisce bandiera per il compilatore. È possibile ottenere le informazioni analizzando l'output di /lib/libc.so.6 (quella biblioteca può essere eseguito direcly come un eseguibile normale). Lascio i dettagli a voi, ma gli sguardi di output come:

Thread di Linux:

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

(anche se, cercate di codice piuttosto di scrittura che non ha bisogno per affrontare questo. Finora, non abbiamo incontrato alcuna necessità di questo nelle nostre applicazioni multithread che girano su RHEL 4 (linuxthreads) vs RHEL 5 (NPTL ))