Читаю вот тут:
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
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Читать надо внимательнее:
>> Возможно ли разогнать их на разные процессоры, или это ребячество одно?
Можно, они для этого и нужны.
на разные процессоры можн разогнать только процессы, т.к. для этго нужен PID, а поток не имеет PIDa (точнее имеет, но немного другой).
А нафига тогда процессоры с общей памятью.
Если используешь процессы, то такая хрень (за такие бабки) никому не нужна.
Многопоточное приложение выигрывает при:
1. Верно избранном дизайне
2. Обходе граблей COW для разных потоков.
3. Максимальной независимости потоков.
Все это не имеет никакого отношения к количеству процессоров и мультипрограммированию вообще. Это сугубо бонусная плюшка релизованная ясное дело программо в диспетчере процессов в твоей ОС.
А основной бонус в том, что процессору не нужно подгружать контекст процесса и производить переключение на новый процесс вообще.
Блин, в этом-то и был вопрос. pthreads — они user-level или kernel-level? То, что clone() — kernel-level, это-то я прочитал. А где связь с pthreads library?
Если они (pthreads) kernel-level, я завтра про них детям расскажу. А если как в Джаве или Аде, то гори они огнем.
И если они user-level, то разогнать их по процессорам невозможно, поскольку ядру они видятся одним процессом.
Good Luck,
UT
Судя по тому, что я читаю, разогнать можно kernel-level threads. Если для имплементации нити использован clone(), даже если от юзверя это скрыто, то PID у них будут.
Или нет?
Good Luck,
UT
Не понял, о чем это ты?
Good Luck,
UT
Это понятно.
А вот это нет. Имеют pthread’ы каждая своё место в task-vector’е или весь клубок там записан под одним номером? В этом самая суть моего вопроса.
То есть, нет? И pthread’ы — это просто забава для программеров? Тогда почему в начале первой ссылки написано, что при использовании многопроцессорной архитектуры получается выигрыш?
Good Luck,
UT
На самом деле все сильно зависит от kernel и конкретной библиотеки. Почитайте
http://people.redhat.com/drepper/nptl-design.pdf
Ну вот не надо только, а? Создание процесса занимает гораздо больше времени, чем pthread-а. И ресурсов на него тратится меньше.
Нет, у потока нету PID-a. Есть некий процесс-координатор потоков программы, при создании потока он создается, связан с реализацией pthreads в конкретной системе. Но эттт процесс может координировать сразу кучу потоков.
Вот, цитата из Стивенса:
Только этот идентификатор потока — это не что иное, как значение типа pthread_t, получаемое при создании потока функцией pthread_create. Как-либо оперировать с потоком внешне, как это делается с процессами, невозможно. Эти значения ThreadID типа pthead_t могут быть одинаковыми двух потоков, имеющих разные родительские процессы. Так что о каком внешнем управлении может идти речь?
P.S.
Посмотри у Стивенса в книге «UNIX: разработка сетевых приложений» (W. Richard Stevens: UNIX Network Programming, Networking APIs) в главе «Программные потоки», там это все замечательно описано. Можно прямо оттуда цитаты студентам давать. Стивенс замечательно пишет.
LONGOBARD, я все это читал, и примеры писал и маны изучал. Я не про то спрашиваю, а про конкретную реализацию одной вещи, PThreads. Как она сделана на Линуксе, на уровне ядра, на пользовательском уровне или немножко того и другого. Разные места говорят по-разному, судя по тому, что написал sas, это вообще неизвестно.
Согласись, реализовать нитку можно по-разному, тот же clone() создаст тебе полноценный процесс, отличающийся от родителя только стеком — чем тебе не нитка? Под Стивенсово определение подогнать — нефик делать.
Ну а можно в программе захерачить класс «шнурок», насоздавать объектов и делить между ними время в бесконечном цикле.
А уж какое там ID — не ID — какое сделали, такое и ID.
И скорость создания процесса/нитки, в общем-то, имеет значение только если они у тебя создаются в зверском количестве и постоянно.
В общем, дело ясное, что дело темное. Ладно, скажу детям про clone() — у меня пример есть, и про PThreads, поскольку safe и наворочено (и опять же, примеры есть). Сегодня еще про sigaction надо будет потолковать… В пятницу — SystemV IPC, и покончим с этим делом. Перейдем к сетевым приладам.
Всем спасибо.
Good Luck,
UT
что-то у вас как-то «галопом по европам». Венигрета не будет в головах студентов? IPC — там мнго чего, за пару дней не пройдешь.
Не, не будет. Вне зависимости от того, чтО именно я делаю, в голове у студентов ничего не будет, — проверено. :-) Шутю.
Не, я имею в виду, в пятницу я начну говорить про IPC, эта тема еще затрагивается у моего коллеги в Operating Systems, как раз вчера мы обсуждали, чтО я говорю, а чтО — он. Ну и моя философия — говорить много можно, а вот дам я им проект — они сами во всем и разберутся, что надо. Не разберутся — спросят. Я им объясняю конструкцию, даю примеры и информацию в лекциях. А дальше они сами должны…
Я считаю, программизм надо изучать пальцами, а не жопой. Я его сам так изучал.
Вообще, система тут — нипель. Я пришел на департмент, мне сказали, вот, графику надо бы прочитать. Дали книгу, сказали, вот эти главы неплохо бы покрыть. Я покрыл. Во втором семестре: «Ты преподаешь Линукс и ИИ. Выбирай себе книжки, планируй курсы. Иди работай». Вот и вся продуманная программа…
Good Luck,
UT
А, ну тогда все правильно делаешь :))))
НЕ ИМЕЮТ, во всяком случае NTPL и WinNT kernel32.dll точно. Нет никакого смысла создавать ТАКИЕ потоки, так как теряем всю бонусность потоков ваще. Для процесора все потоки — ОДИН процесс.
Понятно, спасибо. Значит, баловство это одно. На разные процессоры их не раскидаешь, разве что четвертый пень уловит параллельность кода и оптимизирует его, как сочтет нужным….
Good Luck,
UT
Посмотри как это сделано в LinuxThreads. Про них я ничего не знаю.
Совсем точно не знаю, но все же это описано в linux pthread faq. В отличие от других ОС в линуксе поток представляет собой процесс уровня ядра, именно поэтому для его создания используется системный вызов clone. Однако, все-таки это не совсем обычный процесс при создании программой 2-го потока (1-й всегда есть), создается процесс-нянька, который управляет потоками этого процесса, такая реализация позволила избавиться от второго планировщика для потоков в ядре и сложных алгоритмах их взаимодействия. Как я понимаю, библиотека потоков и представляет из себя этот планировщик для потоков и механизмы синхронизации между ними. Потоки linux не являются полностью posix совместимыми, хотя близки к этому. Развитие этой библиотеки прекращено, ее должны заменить потоки nptl. Потоки ntpl должны избавиться от процесса-няньки и стать posix совместимыми, также обладать лучшими характеристиками.
1) pthreads = POSIX threads — это интерфейс принятый как стандарт (названия ф-ций и прочее). О реальзации каждый заботится как может.
2) Во FreeBSD pthreads реализованы как KSE (Kernel-Sheduling Entities) и являются комбинированными kernel- и user-level.
3) В Linux AFAIK, на данный момент, это сделано как кастрированные процессы, разделяющие единое адресное пространство.
Поэтому они называются LWP (Lightweight processes) или KThreads (Kernel Threads), по ссылке выше Дреппер же написал раньше было плохо, мапились один к одному на ядерные нитки, объектов синхронизации ядерных и кошерных не было, сигналы не ловились, в НПТЛ все изменилось к лучшему, типа дизайн по прежнему 1:1, но без вспомогательных потоков, были реализованы футексы в ядре, ну и локальная для потоков память, рай и благоденствие воцарилось на земле, хота на соляре все равно потоки круче
На какой ? 2.5 — M:N, >=8 — 1:1.