Существуют ли конкретные определения linuxthreads и nptl? - PullRequest
2 голосов
/ 18 августа 2010

У меня есть программа, которая должна работать по-разному для linuxthreads и nptl.

Есть ли в этих библиотеках определения, которые можно использовать в моей программе для определения, используется ли nptl или linuxthreads?

UPDATE1: для времени выполнения есть getconf GLIBC_LIBPTHREADS, но что для времени компиляции?

Ответы [ 3 ]

4 голосов
/ 11 ноября 2010

Не похоже, что это возможно, вы можете изменить реализацию во время загрузки, чтобы не было возможности узнать во время компиляции, что бы вы ни делали.

со страницы руководства pthreads:

В системах с поддержкой glibc как LinuxThreads, так и NPTL (т.е. glibc 2.3.x), 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. Вы просто не можете этого сделать, потому что это не то, что известно во время компиляции, по крайней мере, не так, как вы можете положиться.

Вы должны будете найти какой-нибудь способ использовать обнаружение во время выполнения, или, возможно, вы могли бы обновить свой пост информацией о ПОЧЕМУ вы хотите сделать это, и кто-то может, возможно, дать совет о том, как сделать это каким-то другим способом, или как чтобы сделать возможным использование во время выполнения определения того, какие pthreads используются.

Другое возможное решение - добавить опцию к вашему скрипту конфигурации и сделать так, чтобы лицо, компилирующее его, выбирало.

1 голос
/ 12 ноября 2010

После просмотра заголовков, нет - нет конкретных определений для 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))

1 голос
/ 11 ноября 2010

Давайте сделаем шаг назад и спросим - почему вы хотите это сделать?

Существуют ли функции, которые один обеспечивает, а другой нет? Если это так, возможно, вы можете использовать dlsym на libpthread.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;

Очень хакерский и очень уродливый, но просто выбрасывающий подобные идеи в качестве возможного обходного пути ...

...