LINUX.ORG.RU

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

 ,


0

2


Последнее исправление: Indaril_Shpritz (всего исправлений: 1)

Ответ на: комментарий от Eddy_Em

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от tensai_cirno

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от Indaril_Shpritz

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Eddy_Em

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

UVV ★★★★★
()
Ответ на: комментарий от Eddy_Em

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от Indaril_Shpritz

Правильно ли я понимаю, что 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

sf ★★★
()
Последнее исправление: sf (всего исправлений: 1)
Ответ на: комментарий от Eddy_Em

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

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

korvin_ ★★★★★
()
Ответ на: комментарий от exception13

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от Indaril_Shpritz

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

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

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

sf ★★★
()
Ответ на: комментарий от sf

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от intelfx

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от intelfx

Ага, всё так.

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

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

/thread

intelfx ★★★★★
()
Ответ на: комментарий от Indaril_Shpritz

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

не отвечает.

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от Indaril_Shpritz

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

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

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

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

sf ★★★
()
Ответ на: комментарий от sf

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

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

Indaril_Shpritz
() автор топика
Ответ на: комментарий от Indaril_Shpritz

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

intelfx ★★★★★
()
Ответ на: комментарий от Indaril_Shpritz

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

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

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

sf ★★★
()
Ответ на: комментарий от Indaril_Shpritz

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

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

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

sf ★★★
()
Ответ на: комментарий от sf

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

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

(т.е. их код)

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

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

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

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

Indaril_Shpritz
() автор топика

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

Archer73
()
Ответ на: комментарий от Indaril_Shpritz

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

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

intelfx ★★★★★
()
Ответ на: комментарий от Indaril_Shpritz

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

intelfx ★★★★★
()
Ответ на: комментарий от Indaril_Shpritz

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Archer73

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

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

Pavval ★★★★★
()
Ответ на: комментарий от Eddy_Em

Единой реализации 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.

Ку?

esandmann
()
Ответ на: комментарий от Archer73

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

anonymous
()

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

wakuwaku ★★★★
()
Ответ на: комментарий от Indaril_Shpritz

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

(т.е. их код)

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

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

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

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

В одном.

sf ★★★
()

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

a1batross ★★★★★
()

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

kim-roader ★★
()

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

anonymous
()
Ответ на: комментарий от Archer73

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

anonymous
()
Ответ на: комментарий от hateyoufeel

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.