NTPL или LinuxThreads срочно

$ /lib/libc.so.6

2grob:

Thanks, помогло. (Кто б мог подумать... Совсем старый стал! :-))

Кстати, не совсем straightforward:

root$ /lib/libc.so.6

-bash: /lib/libc.so.6: No such file or directory

и только после некоего раздумия,

root$ /lib/tls/libc.so.6.1 . . . NPTL 0.60 by Ulrich Drepper . . .

(RedHat в инкарнации SGI)

Лучше так:

getconf GNU_LIBPTHREAD_VERSION

Cantor:

Thanks.

В принцип, помогает:

$ getconf GNU_LIBPTHREAD_VERSION

NPTL 0.60

Но смущает:

$ man getconf

No manual entry for getconf

$ getconf --help

getconf: Unrecognized variable `--help'

$ getconf -help

getconf: Unrecognized variable `-help'

$ getconf

Usage: getconf [-v specification] variable_name [pathname] getconf О, оказалось, это -- только под Красной Шапкой. Под СюЗЕй man getconf отвечает, но лепит нечто очень общее... Впрочем, вполне разбираемое.

Типа это...

root@pro-w-01:~# /lib/libc.so.6 | grep thread
        linuxthreads-0.10 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc
root@pro-w-01:~# getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.5

И как это понимать?

Zulu:

Хороший вопрос!

Что называется, "Была бы шляпа -- снял бы..."

К (моему) счастью, у меня они совпадают.

$ /lib/libc.so.6
<...>
Native POSIX Threads Library by Ulrich Drepper et al
<...>

$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.6

Так что как насчет grep Thread ;) Потому как glibc можно собрать с NPTL и linuxthreads одновременно.

> как насчет grep Thread

$ /lib/libc.so.6 |grep -i thread
        linuxthreads-0.10 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc
Thread-local storage support included.
$ getconf GNU_LIBPTHREAD_VERSION
NPTL 2.3.6
$

Во многих современных дистрах актуальный libc.so.6 лежит в /lib/tls, а тот, который в /lib - для обратной совместимости. Вот почему надо проверять с помощью getconf GNU_LIBPTHREAD_VERSION, а не /lib/libc.so.6 | grep thread

2Cantor:

> Во многих современных дистрах актуальный libc.so.6 лежит в /lib/tls, а тот, который в /lib - для обратной совместимости.

Мой случай (хотя у меня в /lib вообше libc6 не лежит).

А не подкинешь ссылки на что почитать? Я даже не подозревал о том, что libc.so.6 может быть где-то в отличном от /lib месте.

Сильно подозреваю. что уши от Красной Шапки растут...

grob:

> ...Потому как glibc можно собрать с NPTL и linuxthreads одновременно.

А это как? Впервые слышу про такое...

И кто из них прилинкуется на -lpthread?

А какое между ними принципиальное отличие. Я в этом деле полный чайник - интересно.

> А какое между ними принципиальное отличие

Большое! :) Погугли...

Мой же вопрос не в этом состоял, а в том, как примирить две различные библиотеки с одинаковым АБИ, вкомпиленным в один бинарник.

Я имел ввиду то, что Cantor уже описал. В частности, в gentoo если собрать glibc с nptl и без linuxthreads, то будет одна /lib/libc.so.6, а если с поддержкой обоих, то используемая по умолчанию с nptl будет в /lib/tls, а с linuxthreads для fallback - в /lib. То есть на самом деле glibc просто будет собираться дважды - с nptl и linuxthreads.

> И кто из них прилинкуется на -lpthread?

зависит от ядра. двойные глибцы собирались в дистрах на ранних версиях 2.6, чтобы в случае чего, пользователь мог безболезненно откатиться на ветку 2.4

> linuxthreads-0.10 by Xavier Leroy

такая же фигня

а Xavier Leroy -- это тот, который окамль разрабатывает?

>>>актуальный libc.so.6 лежит в /lib/tls, а тот, который в /lib - для обратной совместимости

А как такое может быть, что актуальная библиотека лежит в директории про которую ldconfig ничего не знает? Я считал, что линковщик знает только про библиотеки, которые прописаны в /etc/ld.so.conf или в переменной LD_LIBRARY_PATH. Т.е. если /lib/tls в /etc/ld.so.conf не значится - то и библиотека /lib/tls/libc.so.6 не актуальная.

/lib и /usr/lib тоже не прописаны, однако поиск там идет. эти пути зашиваются в линкер при компиляции. так-же, как и /lib/tls.

> зависит от ядра. двойные глибцы собирались в дистрах на ранних версиях 2.6, чтобы в случае чего, пользователь мог безболезненно откатиться на ветку 2.4

На Слаке до сих пор.

Час от часу не легче :(
Как же тогда конфликты разруливаются, если в /lib и /lib/tls одни и те же библиотеки лежат и оба пути вкомпилированы в glibc? С ld.conf как-то более менее понятно: "кто первый встал - того и тапки".

конфликты разруливаются на уровне линкера. и то, и то - часть glibc.

>>На Слаке до сих пор.

Слака вообще по-умолчанию ядра 2.4.x использует. 2.6 в ней - на любителей. Поэтому и двойной glibc - в /lib лежит библиотека для ядер 2.4 c linuxthreads , а в /lib/tls - для ядер 2.6 с ntpl.

Тогда вопрос аналогичный исходному - как узнать, в каких каталогах ldconfig ищет библиотеки? В man ldconfig на этот счёт сказано только следующее:

ldconfig creates the necessary links and cache to the most
recent shared libraries found in the directories specified
on the command line, in the file /etc/ld.so.conf, and in
the trusted directories (/lib and /usr/lib).

Ага, и "конфликты" разруливаются в зависимости от загруженного ядра.

root:~# /lib/libc.so.6 | grep -i thread
        linuxthreads-0.10 by Xavier Leroy
        libthread_db work sponsored by Alpha Processor Inc
Thread-local storage support included.
root:~# /lib/tls/libc.so.6 | grep -i thread
        Native POSIX Threads Library by Ulrich Drepper et al
Thread-local storage support included.
root:~# ldd /bin/bash | grep libc.so.6
        libc.so.6 => /lib/tls/libc.so.6 (0xb7e16000)

А вот и собака зарытая:
root:~# ldconfig -p | grep libc.so.6
        libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.6.0) => /lib/tls/libc.so.6
        libc.so.6 (libc6, OS ABI: Linux 2.2.0) => /lib/libc.so.6

Я всегда использую рантайм-метод (имхо, это надёжнее всего). 
Только вот версию библиотеки так не узнаешь.

Просто компилирую и пользуюсь такой программуськой:

#include <pthread.h>
#include <string.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>

void *detector(void *zero) {
    return (void *)getpid();
}

int main() {
    pthread_t detector_thread;
    pid_t child_pid;
    int err;

    if((err = pthread_create(&detector_thread, NULL, detector, NULL)) != 0) {
        printf("pthread_create failed: %s\n", strerror(err));
        return -1;
    }

    if((err = pthread_join(detector_thread, (void**)&child_pid)) != 0) {
        printf("pthread_join failed: %s\n", strerror(err));
        return -1;
    }

    if(child_pid == getpid())
        printf("***** NPTL detected\n");
    else
        printf("***** LinuxThreads detected\n");

    return 0;
}

насколько я знаю на последних ядрах 2.4.хх это будет давать неправильный результат

# ldconfig -p | grep libc.so.6
        libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.6.4) => /lib/tls/libc.so.6
        libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6
        libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6

Бугага :) SUSE 10.0

блин, ну причём тут ядро-то? с чёго вы это взяли? если есть экспериментальные результаты - покажите, зачем говорить пустые слова...

Как это причём ядро? Zulu же показал пример с ldconfig -p - выбранная библиотека зависит от ядра.

У меня так же будет, если сказать apt-get install libc6-i686

Да ведь дело не в том, сколько в системе ядер, глибцов и прочей хрени. Дело-то в том, какая библиотека pthread будет использована для запущенной мультитредовой программы. Рантайм-метод это и проверяет.

>Рантайм-метод это и проверяет.

проверяЛ.

если мне не изменяет память то гдето в районе версии 2.4.28 в ядре была реализована возможность обеспечения одного PID для всех тредов linuxthreads одно процесса как в NTPL.

как поддерживается эта фича в libc я не знаю но ps перестал видеть кучу процессов для многотредового приложения (например java) а видит их столько сколько есть на самом деле

А у меня так(mandriva2005):

ldconfig -p | grep libc.so.6
libc.so.6 (libc6, hwcap: 0x8000000000000000, OS ABI: Linux 2.4.25) => /lib/tls/libc.so.6
libc.so.6 (libc6, hwcap: 0x8000000000000, OS ABI: Linux 2.4.1) => /lib/i686/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6

2cvv. Этого не может быть. Если это так, покажите release news ядра/glibc, changelog-s. Зачем вы постоянно говорите голые слова? Где факты?

В последних версиях ядра 2.4.XX может использоваться NPTL, это да (например, в RHEL3 это так). LinuxThreads никаким специальным образом с ядром не связана и всегда имеет разные PID-ы для разных тредов.

> Зачем вы постоянно говорите голые слова? Где факты?

> ps перестал видеть кучу процессов для многотредового приложения
> (например java) а видит их столько сколько есть на самом деле

А это всего лишь означает, что на данной системе заиспользовалась NPTL.

>А это всего лишь означает, что на данной системе заиспользовалась NPTL.

Система кажись slackware 10.0

ядро ванильное с kernel.org

откудова там NTPL взятся?

>ядро ванильное с kernel.org

в смысле родное слаковское

Какая же связь между "ядро ванильное" и "откудова там NPTL"?

>Какая же связь между "ядро ванильное" и "откудова там NPTL"?

мож я криво выразился но ямел ввиду что в ядрах 2.4.хх которые лежат на kernel.org никогда небыло NPTL.

Да блин... Ядро как таковое _никакого_ отношения к NPTL не имеет! NPTL - это всего лишь отдельная библиотека, обычно идёт как часть glibc. В отличие от LinuxThreads (которая тоже всего лишь отдельная библиотека), NPTL требует некоторой поддержки от ядра, например, системный вызов tkill.

В ядре 2.6 и в последних микроверсиях 2.4 таковая поддержка появилась.

Почитайте хоть что-нибудь по NPTL (в гугле сколько угодно ссылок). Зайдите на сайт автора, Ulrich Drepper. Вот его документ: http://people.redhat.com/drepper/nptl-design.pdf.

>Ядро как таковое _никакого_ отношения к NPTL не имеет!

естественно, просто предоставляет пару-тройку сисколов

>В отличие от LinuxThreads (которая тоже всего лишь отдельная библиотека), NPTL требует некоторой поддержки от ядра

вы б ещё сказали что LinuxThreads на форках(sys_fork) работает.

вобщем мои познания в реализации тредов слегка прихрамывают, посему предлагаю не продолжать. Всё равно без Idle OR Murr до истины недокопаемся

> вы б ещё сказали что LinuxThreads на форках(sys_fork) работает.

К чему эта реплика? Что вы хотите этим сказать?

Если ваши познания прихрамывают, и вы это сами сознаёте (!!), зачем вы вступаете в дискуссию, вынужная отвечать вам на ваши неверные замечания? Если прихрамывают, так почитайте что-нибудь, а потом уже что-то позволяйте себе что-либо утвержать!

справедливости ради, NPTL потребовала довольно
серьезных изменений в core kernel, и добавленные
в качестве бонуса ошибки расхлебываются по сию
пору. начать хотя бы с того, что в ядре просто
отсутсвовало такое понятие как поток во времена
LinuxThreads.

я бы даже наоборот сказал. NPTL стала создавться
после того, как изменения в ядре сделали это
возможным.