Существуют ли конкретные определения linuxthreads и nptl?

Question

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

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

ОБНОВЛЕНИЕ 1: Для времени выполнения есть getconf GLIBC_LIBPTHREADS, но что для времени компиляции?

Answer 1

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

со страницы руководства 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 используется.

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

Answer 2

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

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

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

Answer 3

После просмотра заголовков, нет - нет конкретных определений для NPTL против LinuxThreads.

Если вам нужно такое определение, напишите небольшой скрипт, который создает файл заголовка, или передайте флаг определения компилятору. Вы можете получить информацию, проанализировав вывод /lib/libc.so.6 (эта библиотека может быть запущена непосредственно как обычный исполняемый файл). Я оставлю вам детали, но результат выглядит так:

LinuxThreads:

Версия 2.3.4 стабильной версии библиотеки GNU C, Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
Это бесплатное программное обеспечение; см. источник для условий копирования.
Там нет гарантии; даже не для ТОРГОВЛИ или пригодности для
КОНКРЕТНОЕ НАЗНАЧЕНИЕ.
Составлено GNU CC версии 3.4.6 20060404 (Red Hat 3.4.6-11).
Скомпилировано в системе Linux 2.4.20 2010-04-18.
Доступные расширения:
        GNU libio Пер Ботнер
        дополнение к склепу версии 2.1 от Michael Glad и других
        linuxthreads-0.10 Ксавье Леруа
        Дополнение к заглушкам C версии 2.1.2.
        BIND-8.2.3-T5B
        Модули NIS(YP)/NIS+ NSS 0.19, Торстен Кукук
        Glibc-2.0 совместимость дополнения от Cristian Gafton
        GNU Libidn от Саймона Йозефссона
        Работа libthread_db спонсируется Alpha Processor Inc
Потоковая поддержка локального хранилища включена.
Инструкции по сообщению об ошибках смотрите:,

NPTL:

Версия 2.5 стабильной версии библиотеки GNU C, Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
Это бесплатное программное обеспечение; см. источник для условий копирования.
Там нет гарантии; даже не для ТОРГОВЛИ или пригодности для
КОНКРЕТНОЕ НАЗНАЧЕНИЕ.
Составлено GNU CC версии 4.1.2 20080704 (Red Hat 4.1.2-48).
Скомпилировано в системе Linux 2.6.9 2010-10-25.
Доступные расширения:
        Дополнение к заглушкам C версии 2.1.2.
        дополнение к склепу версии 2.1 от Michael Glad и других
        GNU Libidn от Саймона Йозефссона
        GNU libio Пер Ботнер
        Модули NIS(YP)/NIS+ NSS 0.19, Торстен Кукук
        Библиотека нативных потоков POSIX, автор Ulrich Drepper и др.
        BIND-8.2.3-T5B
        RT с использованием ядра Linux AIO
Потоковая поддержка локального хранилища включена.
Инструкции по сообщению об ошибках смотрите:,

(хотя, попробуйте написать код, который не должен иметь дело с этим. До сих пор мы не сталкивались с необходимостью в наших многопоточных приложениях, работающих на RHEL 4(linuxthreads) по сравнению с RHEL 5(NPTL))