nixp.ru v3.0

18 апреля 2024,
четверг,
10:57:58 MSK

Uncle Theodore написал 15 февраля 2005 года в 23:41 (1379 просмотров) Ведет себя неопределенно; открыл 58 тем в форуме, оставил 1537 комментариев на сайте.

Читаю вот тут:

http://www.yolinux.com/TUTORIALS/LinuxTutorialPosixThreads.html

-- получается, что они POSIX-совместимые нити. Читаю вот тут:

http://www.serpentine.com/~bos/threads-faq/#9-Unix-Are-there-any-freely-available-threads-packages-

и ниже, в 19, выходит, pthreads являются user-level нитями?

Ничего не понимаю. Вопрос:

pthreads — они user-level или kernel-level?

Возможно ли разогнать их на разные процессоры, или это ребячество одно?

Те pthreads, которые mutex и прочая лабуда, они POSIX-стандартны или нет?

Good Luck,

UT

iliya

Читать надо внимательнее:

Linux Linux 1.2.13 and above user / kernel 1c, DCE see free implementations for several packages

Linux 2.x kernel n/a clone() interface

>> Возможно ли разогнать их на разные процессоры, или это ребячество одно?

Можно, они для этого и нужны.

Longobard

на разные процессоры можн разогнать только процессы, т.к. для этго нужен PID, а поток не имеет PIDa (точнее имеет, но немного другой).

iliya
LONGOBARD
на разные процессоры можн разогнать только процессы, т.к. для этго нужен PID, а поток не имеет PIDa (точнее имеет, но немного другой).

А нафига тогда процессоры с общей памятью.

Если используешь процессы, то такая хрень (за такие бабки) никому не нужна.

decvar

Многопоточное приложение выигрывает при:

1. Верно избранном дизайне

2. Обходе граблей COW для разных потоков.

3. Максимальной независимости потоков.

Все это не имеет никакого отношения к количеству процессоров и мультипрограммированию вообще. Это сугубо бонусная плюшка релизованная ясное дело программо в диспетчере процессов в твоей ОС.

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

Uncle Theodore
iliya
Читать надо внимательнее:

Linux Linux 1.2.13 and above user / kernel 1c, DCE see free implementations for several packages

Linux 2.x kernel n/a clone() interface

>> Возможно ли разогнать их на разные процессоры, или это ребячество одно?

Можно, они для этого и нужны.

Блин, в этом-то и был вопрос. pthreads — они user-level или kernel-level? То, что clone() — kernel-level, это-то я прочитал. А где связь с pthreads library?

Если они (pthreads) kernel-level, я завтра про них детям расскажу. А если как в Джаве или Аде, то гори они огнем.

И если они user-level, то разогнать их по процессорам невозможно, поскольку ядру они видятся одним процессом.

Good Luck,

UT

Uncle Theodore
LONGOBARD
на разные процессоры можн разогнать только процессы, т.к. для этго нужен PID, а поток не имеет PIDa (точнее имеет, но немного другой).

Судя по тому, что я читаю, разогнать можно kernel-level threads. Если для имплементации нити использован clone(), даже если от юзверя это скрыто, то PID у них будут.

Или нет?

Good Luck,

UT

Uncle Theodore
iliya
А нафига тогда процессоры с общей памятью.

Если используешь процессы, то такая хрень (за такие бабки) никому не нужна.

Не понял, о чем это ты?

Good Luck,

UT

Uncle Theodore
decvar
Многопоточное приложение выигрывает при:

1. Верно избранном дизайне

2. Обходе граблей COW для разных потоков.

3. Максимальной независимости потоков.

Это понятно.

Все это не имеет никакого отношения к количеству процессоров и мультипрограммированию вообще. Это сугубо бонусная плюшка релизованная ясное дело программо в диспетчере процессов в твоей ОС.

А вот это нет. Имеют pthread’ы каждая своё место в task-vector’е или весь клубок там записан под одним номером? В этом самая суть моего вопроса.

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

То есть, нет? И pthread’ы — это просто забава для программеров? Тогда почему в начале первой ссылки написано, что при использовании многопроцессорной архитектуры получается выигрыш?

Good Luck,

UT

sas

На самом деле все сильно зависит от kernel и конкретной библиотеки. Почитайте

http://people.redhat.com/drepper/nptl-design.pdf

Longobard
То есть, нет? И pthread’ы — это просто забава для программеров? Тогда почему в начале первой ссылки написано, что при использовании многопроцессорной архитектуры получается выигрыш?

Ну вот не надо только, а? Создание процесса занимает гораздо больше времени, чем pthread-а. И ресурсов на него тратится меньше.

Longobard
Uncle Theodore
Судя по тому, что я читаю, разогнать можно kernel-level threads. Если для имплементации нити использован clone(), даже если от юзверя это скрыто, то PID у них будут.

Или нет?

Good Luck,

UT

Нет, у потока нету PID-a. Есть некий процесс-координатор потоков программы, при создании потока он создается, связан с реализацией pthreads в конкретной системе. Но эттт процесс может координировать сразу кучу потоков.

Вот, цитата из Стивенса:

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

………………………….

У каждого потока имеется свой:

1) стек

2) errno

3) маска сигналов

4) приоритет

5) идентификатор потока

……………..

Только этот идентификатор потока — это не что иное, как значение типа pthread_t, получаемое при создании потока функцией pthread_create. Как-либо оперировать с потоком внешне, как это делается с процессами, невозможно. Эти значения ThreadID типа pthead_t могут быть одинаковыми двух потоков, имеющих разные родительские процессы. Так что о каком внешнем управлении может идти речь?

P.S.

Посмотри у Стивенса в книге «UNIX: разработка сетевых приложений» (W. Richard Stevens: UNIX Network Programming, Networking APIs) в главе «Программные потоки», там это все замечательно описано. Можно прямо оттуда цитаты студентам давать. Стивенс замечательно пишет.

Uncle Theodore

LONGOBARD, я все это читал, и примеры писал и маны изучал. Я не про то спрашиваю, а про конкретную реализацию одной вещи, PThreads. Как она сделана на Линуксе, на уровне ядра, на пользовательском уровне или немножко того и другого. Разные места говорят по-разному, судя по тому, что написал sas, это вообще неизвестно.

Согласись, реализовать нитку можно по-разному, тот же clone() создаст тебе полноценный процесс, отличающийся от родителя только стеком — чем тебе не нитка? Под Стивенсово определение подогнать — нефик делать.

Ну а можно в программе захерачить класс «шнурок», насоздавать объектов и делить между ними время в бесконечном цикле.

А уж какое там ID — не ID — какое сделали, такое и ID.

И скорость создания процесса/нитки, в общем-то, имеет значение только если они у тебя создаются в зверском количестве и постоянно.

В общем, дело ясное, что дело темное. Ладно, скажу детям про clone() — у меня пример есть, и про PThreads, поскольку safe и наворочено (и опять же, примеры есть). Сегодня еще про sigaction надо будет потолковать… В пятницу — SystemV IPC, и покончим с этим делом. Перейдем к сетевым приладам.

Всем спасибо.

Good Luck,

UT

Longobard

что-то у вас как-то «галопом по европам». Венигрета не будет в головах студентов? IPC — там мнго чего, за пару дней не пройдешь.

Uncle Theodore
LONGOBARD
что-то у вас как-то «галопом по европам». Венигрета не будет в головах студентов? IPC — там мнго чего, за пару дней не пройдешь.

Не, не будет. Вне зависимости от того, чтО именно я делаю, в голове у студентов ничего не будет, — проверено. :-) Шутю.

Не, я имею в виду, в пятницу я начну говорить про IPC, эта тема еще затрагивается у моего коллеги в Operating Systems, как раз вчера мы обсуждали, чтО я говорю, а чтО — он. Ну и моя философия — говорить много можно, а вот дам я им проект — они сами во всем и разберутся, что надо. Не разберутся — спросят. Я им объясняю конструкцию, даю примеры и информацию в лекциях. А дальше они сами должны…

Я считаю, программизм надо изучать пальцами, а не жопой. Я его сам так изучал.

Вообще, система тут — нипель. Я пришел на департмент, мне сказали, вот, графику надо бы прочитать. Дали книгу, сказали, вот эти главы неплохо бы покрыть. Я покрыл. Во втором семестре: «Ты преподаешь Линукс и ИИ. Выбирай себе книжки, планируй курсы. Иди работай». Вот и вся продуманная программа…

Good Luck,

UT

Longobard

А, ну тогда все правильно делаешь :))))

decvar
А вот это нет. Имеют pthread’ы каждая своё место в task-vector’е или весь клубок там записан под одним номером? В этом самая суть моего вопроса.

НЕ ИМЕЮТ, во всяком случае NTPL и WinNT kernel32.dll точно. Нет никакого смысла создавать ТАКИЕ потоки, так как теряем всю бонусность потоков ваще. Для процесора все потоки — ОДИН процесс.

Uncle Theodore
decvar
НЕ ИМЕЮТ, во всяком случае NTPL и WinNT kernel32.dll точно. Нет никакого смысла создавать ТАКИЕ потоки, так как теряем всю бонусность потоков ваще. Для процесора все потоки — ОДИН процесс.

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

Good Luck,

UT

decvar

Посмотри как это сделано в LinuxThreads. Про них я ничего не знаю.

metal

Совсем точно не знаю, но все же это описано в linux pthread faq. В отличие от других ОС в линуксе поток представляет собой процесс уровня ядра, именно поэтому для его создания используется системный вызов clone. Однако, все-таки это не совсем обычный процесс при создании программой 2-го потока (1-й всегда есть), создается процесс-нянька, который управляет потоками этого процесса, такая реализация позволила избавиться от второго планировщика для потоков в ядре и сложных алгоритмах их взаимодействия. Как я понимаю, библиотека потоков и представляет из себя этот планировщик для потоков и механизмы синхронизации между ними. Потоки linux не являются полностью posix совместимыми, хотя близки к этому. Развитие этой библиотеки прекращено, ее должны заменить потоки nptl. Потоки ntpl должны избавиться от процесса-няньки и стать posix совместимыми, также обладать лучшими характеристиками.

myst

1) pthreads = POSIX threads — это интерфейс принятый как стандарт (названия ф-ций и прочее). О реальзации каждый заботится как может.

2) Во FreeBSD pthreads реализованы как KSE (Kernel-Sheduling Entities) и являются комбинированными kernel- и user-level.

3) В Linux AFAIK, на данный момент, это сделано как кастрированные процессы, разделяющие единое адресное пространство.

vadik_mironov
myst
3) В Linux AFAIK, на данный момент, это сделано как кастрированные процессы, разделяющие единое адресное пространство.

Поэтому они называются LWP (Lightweight processes) или KThreads (Kernel Threads), по ссылке выше Дреппер же написал раньше было плохо, мапились один к одному на ядерные нитки, объектов синхронизации ядерных и кошерных не было, сигналы не ловились, в НПТЛ все изменилось к лучшему, типа дизайн по прежнему 1:1, но без вспомогательных потоков, были реализованы футексы в ядре, ну и локальная для потоков память, рай и благоденствие воцарилось на земле, хота на соляре все равно потоки круче

anonymous
vadik_mironov
Поэтому они называются LWP (Lightweight processes) или KThreads (Kernel Threads), по ссылке выше Дреппер же написал раньше было плохо, мапились один к одному на ядерные нитки, объектов синхронизации ядерных и кошерных не было, сигналы не ловились, в НПТЛ все изменилось к лучшему, типа дизайн по прежнему 1:1, но без вспомогательных потоков, были реализованы футексы в ядре, ну и локальная для потоков память, рай и благоденствие воцарилось на земле, хота на соляре все равно потоки круче

На какой ? 2.5 — M:N, >=8 — 1:1.

Последние комментарии

ecobeingecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.