¿Hay define específicas de linuxthreads y NPTEL

Question

I hav un programa, que debe funcionar de forma diferente para linuxthreads y NPTL.

¿Hay define en este libs, que puede ser utilizado en mi programa para detectar, se se utiliza NPTL o es linuxthreads es?

Update1:? Para el tiempo de ejecución hay un GLIBC_LIBPTHREADS getconf, pero lo que para el tiempo de compilación

Answer 1

No se ve como esto es posible, se puede cambiar la aplicación en tiempo de carga así que no hay manera de saber en tiempo de compilación, no importa lo que haces.

desde la página pthreads hombre:

  

En los sistemas con una glibc que los apoyos   tanto LinuxThreads y NPTL (es decir,   glibc 2.3.x), el LD_ASSUME_KERNEL   variable de entorno se puede utilizar para   redefinir el valor predeterminado del enlazador dinámico   elección de la aplicación de roscado.   Esta variable le dice al enlazador dinámico   asumir que se está ejecutando en la parte superior de   una versión del kernel en particular. Por   especificar una versión del núcleo que hace   No proporcionar el apoyo requerido por   NTPL, podemos forzar el uso de   LinuxThreads. (La razón más probable   para hacer esto es ejecutar un (roto)   aplicación que depende de alguna   comportamiento no conformes en   LinuxThreads). Por ejemplo:

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

Por no mencionar que las dos implementaciones son (en su mayoría) compatible a nivel binario, así que básicamente no se puede saber en tiempo de compilación que se va a utilizar la biblioteca de hebras, nunca, ya que podría cambiar en función de las variables de entorno presentan cuando se ejecuta el programa, o alguien podría copiar el binario de un sistema NTPL a un sistema de hilos de Linux. Usted simplemente no puede hacerlo, porque no es algo que se conoce en tiempo de compilación, al menos no de una manera que puede confiar.

Vas a tener que encontrar la manera de utilizar la detección en tiempo de ejecución, o tal vez usted podría actualizar el post con información acerca de por qué quiere hacer esto y alguien tal vez podría ofrecer consejos sobre cómo llevar a cabo alguna otra manera, o cómo para que sea posible utilizar la detección de tiempo de ejecución de los cuales pthreads está en uso.

La otra posible solución es añadir una opción para el script de configuración y hacer que la persona elija la compilación.

Answer 2

Vamos a dar un paso atrás y preguntar - ¿por qué quieres hacer esto

¿Hay funciones que uno establece que otro no lo hace? Si es así tal vez puede utilizar dlsym en libpthread.so para consultar dinámicamente su existencia en tiempo de ejecución.

O es más una cuestión de un cierto comportamiento que difiere entre ellos, causando su programa a portarse mal? Si es así, me gustaría evitar depender de los resultados de tales comportamientos, o consultar a un estándar como POSIX para determinar lo que puede confiar. A menudo, estos errores de portabilidad representan defectos reales en su código que puede ser que necesite hacer frente incluso utilizando la biblioteca que Think es "trabajar". Cuando entra en escena concurrencia esto es especialmente importante para hacerlo bien.

Por último, si se trata de una cuestión de los tamaños de las estructuras ... Puede haber formas hacky de todo esto también. Por ejemplo (sólo un ejemplo, puede ser totalmente fuera de la base, pero ilustra la 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;

poco limpia y muy feo, pero sólo tirar este tipo de ideas por ahí como una posible solución ...

Answer 3

Después de mirar a través de los encabezados, no - no hay define específicas para NTPL vs LinuxThreads

.

Si necesita tal definir, escribir un pequeño script que genera un archivo de cabecera, o un pase de definir bandera para el compilador. Puede obtener la información analizando la salida de /lib/libc.so.6 (biblioteca que se puede ejecutar direcly como un ejecutable normal). Voy a dejar los detalles para usted, pero las miradas de salida como:

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

NTPL:

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

(sin embargo, tratar de código en lugar de escritura que no necesita para hacer frente a esto. Hasta ahora, no hemos encontrado ninguna necesidad de esto en nuestras aplicaciones multiproceso que se ejecutan en RHEL 4 (linuxthreads) vs RHEL 5 (NTPL ))