Зачем libpthread если в glibc есть linuxthreads и nptl ?

Приведи примеры одинакового кода во всех трех реализациях для сравнения.

не могу пока - нет понимания
в мане
http://man7.org/linux/man-pages/man7/pthreads.7.html
написано, что linuxthreads - старая имплементация, nptl - новая (более интегрированная с ядром).

А про libpthread там ничего не написано...

glibc всего лишь одна из множественных реализаций libc.

и что из этого следует? Что где-то может встретиться libc без ntpl и тогда потребуется libpthread?

Мне не ясно, libpthread - это то же самое, что ntpl или нет.

А я никогда не встречал реализации потоков без pthreads. Примеры бы посмотреть, а то и самому интересно — неужто есть более простая реализация, но ее не используют по незнанию?

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682516(v=vs.85).aspx

анонимус опередил меня, но в мсдне можешь посмотреть =)

И каким боком тут мастдайка?

не отвлекайся на них, лучше мне по делу развернуто ответь.

Правильно ли я понимаю, что ntpl в glibc сделан на основе libpthread?

Правильно ли я понимаю, что ntpl в glibc сделан на основе libpthread?

Та библиотека по ссылке судя по ссылкам вокруг явдяется частью реализации С бибилотеки для symbian (Open C library).

glibc является библиотекой С для ядра linux. Сама она не реализуем никаких сложных моделей потоков, а берет их прямо из ядра (во FreeBSD, например, есть и userspace реализация).

LinuxThreads - реализация потоков на основе «процессов с общим адресным пространством» (у кождого потока свой pid процесса, обработчик сигналов и т.д.).

В linux 2.6 заменили LinuxThreads реализацию на «исправленную» NPTL с меньшим количеством «особенностей»:

http://cs.uns.edu.ar/~jechaiz/sosd/clases/extras/03-LinuxThreads and NPTL.pdf

это я всё прочитал. А зачем нужна libpthreads?

в смысле - зачем она нужна не в symbian, а для чего её линкуют в программы на linux

Откуда ж я знаю? Я никогда этим ntpl не пользовался. И примеров не видел.

Правильно ли я понимаю, что ntpl в glibc сделан на основе libpthread?

libpthread в glibc сделан на основе ntpl

А я никогда не встречал реализации потоков без pthreads.

Plan 9 libthread. Правда никсовые порты вроде как реализуют ее через libpthread внутрях.

libpthread в glibc сделан на основе ntpl

а зачем, если есть ntpl?
Чем ntpl плох, если реализует тот же стандарт?

в смысле - зачем она нужна не в symbian, а для чего её линкуют в программы на linux

Интерфейс POSIX threads (libpthread.so/.a/.dll, линкующаяся через -lpthread) может реализоваться любой libc (glibc, musl, newlib).

Даже в MacOS есть libpthread.dylib (симлинк на libSystem.dylib).

ну тем более, почему в linux одна и та же динамическая библиотека линкуется и с libpthread и с ntpl glibc (ведь они реализуют один и тот же интерфейс, а значит libpthread не нужен)?

libpthread (он же pthreads) работает через nptl или linuxthreads.

Насколько понимаю, это вещи разного уровня.

то есть это обёртка, которая тупо проксирует один и тот же API, написанный по одному и тому же стандарту?

Почему бы её тогда не исключить из программы в процессе линковки?

Я никогда этим ntpl не пользовался.

очень маловероятно.

http://www.drdobbs.com/open-source/nptl-the-new-implementation-of-threads-f/1...

Ага, всё так.

nptl и linuxthreads — это две разные реализации (обе Linux-специфичные) библиотеки управления потоками. А pthreads (libpthread) — это стандартизированный интерфейс библиотеки управления потоками.

На винде (при использовании mingw) есть библиотека libpthread, у неё совершенно такой же интерфейс с точки зрения прикладного кода, но там нет ни nptl, ни linuxthreads — там своя, специфичная для Win32, реализация.

/thread

Не понял. Почитай моё сообщение выше; может, оно отвечает на твой вопрос.

может, оно отвечает на твой вопрос.

не отвечает.

если программа распространяется специально под linux, то не надо ей знать о существовании windows, а это значит, что лишнюю прослойку можно выкинуть во имя перфоманса.

то есть это обёртка, которая тупо проксирует один и тот же API, написанный по одному и тому же стандарту?

У ядра нет С API. libc является C API к ядру («тупо прокси из syscall ABI в C ABI»).

NPTL API (как и LinuxThreads API) из ядра в userspace - это системные вызовы clone() и futex() (и всякие signal()).

На этих системных вызовах реализуются pthread_*() функции в libc.

На этих системных вызовах реализуются pthread_*() функции в libc.

а поверх них ещё вызовы проксей функций в libpthread, правильно?

Гипотетически можно. Но это C, libpthread и glibc — библиотеки разные, и оптимизации (напр., инлайнинг) между ними проводить невозможно.

> На этих системных вызовах реализуются pthread_*() функции в libc.

а поверх них ещё вызовы проксей функций в libpthread, правильно?

В linux 'libpthread' это и есть часть (g)libc. Никаких proxy.

т.е. libpthread и ntpl это в точности один и тот же код, но два комплекта заголовочных (.h) файлов?

сравни своё сообщение с сообщением sf. Вы говорите взаимоисключающие вещи...

т.е. libpthread и ntpl это в точности один и тот же код, но два комплекта заголовочных (.h) файлов?

libpthread - либа + <pthread.h> с C API с pthread_* функциями (не важно как реализованными).

NPTL (и LinuxThreads :]) - набор примитивов ядра (clone(), futex() и их параметров) для реализации pthread_* функций + сама реализация pthread_*() функций в glibc.

буквально прочитай что ты написал

libpthread - либа ... то есть там есть реализации функций

(т.е. их код)

NPTL - ... + сама реализация ... функций в glibc

(то есть тоже код).

Т.е. мы видим код одних и тех же функций в двух местах - в библиотеке libpthread и в библиотеке glibc...

и обе этих библиотеки с двумя комплектами кода линкуются в нашу программу. Тут либо одно является проксёй для другого, либо ты чего-то недоговариваешь

pthread редко когда действительно нужен. В большинстве прикладных задач OpenMP лучше. Код в несколько раз короче и намного надежней.

Да, похоже на то. Я говорил исходя из общей эрудиции, а sf наверняка в этом более компетентен.

Тем не менее: заинлайнить функции pthread_* в прикладной код (и сделать так, чтобы прикладной код напрямую вызывал то, что называют nptl) невозможно по той же причине.

Ну так да, pthread — это прослойка между прикладным кодом и NPTL/LinuxThreads/чем-то ещё.

Так это ж обычный libpthreads!

а это значит, что лишнюю прослойку можно выкинуть во имя перфоманса.

Сначала найди в этом bottleneck, а потом выкидывай, ламер! Оверхед небольшой прослойки существенно ниже стоимости сисколла, потому толку с «выкидывания» как с козла молока.

pthread редко когда действительно нужен. В большинстве прикладных задач OpenMP лучше.

Facepalm. Ты на openMP пытался сделать не вычислительные задачи?

Единой реализации pthreads тоже нет. pthreads значит всего лишь POSIX threads

POSIX Threads, usually referred to as Pthreads, is a POSIX standard for threads. The standard, POSIX.1c, Threads extensions (IEEE Std 1003.1c-1995), defines an API for creating and manipulating threads.

Ку?

Лол, блядь. Какой нахуй OpenMP в большинстве прикладных задач? Прежде чем вылезать с умными советами, сходи почитай про parallelism и concurrency, может поймешь, о чем вообще речь.

Действительно, зачем нужен pthread когда в C есть треды из коробки?

это называется унификация

> libpthread - либа ... то есть там есть реализации функций

(т.е. их код)

> NPTL - ... + сама реализация ... функций в glibc

(то есть тоже код).

В библиотеке libpthread, которая ставится с пакетом glibc.

Т.е. мы видим код одних и тех же функций в двух местах - в библиотеке libpthread и в библиотеке glibc...

В одном.

pthreads переносимее, популярнее.

libpthread это часть glibc. Также как libm, напрмер. На вопросы по типу «а почему есть некоторые символы которые и в той и в другой библиотеке есть?» ответ можно найти на stackowerflow

А ниче, что glibc есть не везде?

О, а вот и смена Царю подрастает. Такой же упоротый, пафосно изрыгающий несусветную чушь.

Действительно, зачем нужен pthread когда в C есть треды из коробки?

w00t?

http://en.cppreference.com/w/c/thread

И какой только кащенит придумывал названия этим функциям...