Здравствуйте.
Постоянно слышу в различных статьях и форумах о том что потоки в линукс реализованы криво. Последнее время заинтересовался системным программированием, интересует в чем же всё-таки их слабость.
Хотелось бы также получить рекомендации в выборе литературы для правильного
изучения ОС. В данный момент подумываю купить "Современные операционные системы" Таненбаума.PS: Буду очень рад любым ссылкам на бумажную и электронную литературу по указанному вопросу.
Насчет книг - есть хорошая книга Linux Advanved Programming - http://www.advancedlinuxprogramming.com/
Есть в англицком варианте на сайте в pdf формате.
Также она есть в бумажном варианте в русском переводе под названием "Программирование под линукс, Проффесиональный подход" или как-то так,
Там хорошо описано и программирование потоков, и работа с памятью, и сокеты и еще куча всего,Ну а уж совсем настольной книгой должна быть книга У.Р.Стивенса "Unix. Разработка сетевых приложений" и вторая ее часть "Unix. Взаимодействие процессов". Благо она через хорошие издательства прошла, и в русском переводе выпущена уже энным тиражом.
Так что удачи.А насчет потоков под линукс - меня устраивают :) Под другие *nix'ы не писал, так что сравнивать не с чем.
>А насчет потоков под линукс - меня устраивают :) Под другие *nix'ы
>не писал, так что сравнивать не с чем.Кривизна, скорее, эстетического, нежели практического плана.
Ну не нравится мне, когда потоки процесса есть на самом
деле отдельные процессы, а сам процесс - группа оных с главным
потоком в качестве лидера. Мухи - налево, котлеты - направо.
В 2.4+ с NPTL это уже не так :)
>В 2.4+ с NPTL это уже не так :)И слава Богу. Интересно, что шуму вокруг сего новшества
уйма, при всём том, что нет ни одного приличного UNIXа,
его не содержащего.
Вот здесь если можно поподробнее.
Как оно было, есть сейчас, и планируется.
>>В 2.4+ с NPTL это уже не так :)
>
>И слава Богу. Интересно, что шуму вокруг сего новшества
>уйма, при всём том, что нет ни одного приличного UNIXа,
>его не содержащего.
Не думаю, что есть UNIX, поддерживающий NPTL. ;)
Особенность NPTL для Linux не только в соответствии POSIX Threads. Есть еще вопросы производительности (которые эта библиотека решает весьма достойно).
>Не думаю, что есть UNIX, поддерживающий NPTL. ;)Есть много способов назвать одну простую вещь множеством сложных и красивых слов. :)
>Особенность NPTL для Linux не только в соответствии POSIX Threads. Есть еще
>вопросы производительности (которые эта библиотека решает весьма достойно).Опят-таки - и слава Богу! А насчёт сделанной по уму реализации потоков см.
Solaris, HP-UX и Tru64 UNIX.
>Есть много способов назвать одну простую вещь множеством сложных и красивых слов.
>:)Причем тут название то? :) Само название расшифровывается всего навсего как Native POSIX Thread Library. И что за простая вещь, о которой Вы так настойчиво говорите? Вы вообще в курсе, что для Linux есть с десяток реализаций POSIX Threads, начиная с pth и LinuxThreads, заканчивая NGPT и NPTL? В плане интерфейса они все схожи в том смысле, что реализуют один и тот же интерфейс POSIX Threads, но на этом сходство заканчивается, так что Вашу мысль я, похоже, не уловил.
>Опят-таки - и слава Богу!
Да в принципе и на LinuxThreads почти всё работало. :)>А насчёт сделанной по уму реализации потоков см. Solaris, HP-UX и Tru64 UNIX.
Давайте определимся для начала что такое "потоки", а потом будем судить о том, что такое хорошо и что такое плохо. А то пустой разговор получается. :) Ну и дополнительно определимся для чего они нам нужны. :)
>Да в принципе и на LinuxThreads почти всё работало. :)Какой букет: "в принципе" + "почти всё" + ... - одно умиление...
>Опят-таки - и слава Богу! А насчёт сделанной по уму реализации потоков
>см.
>Solaris, HP-UX и Tru64 UNIX.
Воистину. + ещё QNX 6.X
я бы еще сюда AIX добавил. на нем тоже все не слабо сделано.ЗЫ. чем то мне вся эта окололюниховская религия винды напоминает. народ с одного модного демона на другого, более модного, пересаживается. только во вред это люниху, на мой взгляд...
Для начала нужно определиться с тем, что вы называете нитями, а потом уже и смотреть что криво, а что не криво.Начнем с того, что был UNIX на PDP и были на нем процессы и всё было хорошо. Со временем его портировали на большие машины и стали использовать в серьезных приложениях, по ходу дела решили, что лишние переключения контекста MMU вроде как не очень хороши, потому как ощутимо тормозят многопроцессное приложение/систему. И решили делить адресное пространство между потоками управления. Появилось много фирменных реализаций этой идеи и куча стандартов (в частности, всеми любимый POSIX Threads).
Linux 2.4 изнутри сделан очень просто - он не поддерживает на уровне ядра концепций вроде POSIX Threads. Напротив, в нем заложена чрезвычайно простая и очень здравая идея: процесс - это набор атрибутов, включающий файловые дескрипторы, контекст fs, адресное пространство, обработчики сигналов, etc. Эти атрибуты можно разделять между процессами - это то, что было добавлено к идеологии классических процессов. В остальном всё поведение процессов не изменилось. То есть легким движением руки была получена простая модель variable weight processes(vwp) с очень предсказуемым поведением.
Когда говорят, что в Linux "криво сделаны нити" скорее всего имеется в виду тот факт, что библиотека LinuxThreads, которая обычно поставляется с дистрибутивами на базе ядра 2.4, не полностью соответствует стандарту POSIX Threads (разумеется, отчасти из-за особенностей ядра).
>Для начала нужно определиться с тем, что вы называете нитями, а потом
>уже и смотреть что криво, а что не криво.
>
>Начнем с того, что был UNIX на PDP и были на нем
>процессы и всё было хорошо. Со временем его портировали на большиеИстория вопроса не имеет никакого отношения к прямоте либо кривизне
конкретной реализации конкретной функциональности. Исторические ссылки
позволяют объяснить причину кривизны, но не устраняют её.>
>Linux 2.4 изнутри сделан очень просто - он не поддерживает на уровне
>ядра концепций вроде POSIX Threads. Напротив, в нем заложена
>чрезвычайно простая и очень здравая идея: процесс - это набор атрибутов,
>включающий файловые дескрипторы, контекст fs, адресное пространство, >обработчики сигналов, etc. Эти атрибуты можно
>разделять между процессами - это то, что было добавлено к идеологии
>классических процессов. В остальном всё поведение процессов не
>изменилось. То есть легким движением руки была получена простая модель >variable weight processes(vwp) с очень предсказуемым поведением.
>Целью разработчиков было добиться поддержки многопоточности минимальной
кровью. Они этого добились. Практически всегда лучше плохо, но сегодня,
чем хорошо, но когда-нибудь. Что касается идей, то IMHO куда как более
здраво выглядит логическое разделение параллелизма выполнения и
выделяемых некоей системной единице (процессу) ресурсов.>Когда говорят, что в Linux "криво сделаны нити" скорее всего имеется в
>виду тот факт, что библиотека LinuxThreads, которая обычно поставляется
>с дистрибутивами на базе ядра 2.4, не полностью соответствует стандарту
>POSIX Threads (разумеется, отчасти из-за особенностей ядра).Версий оного стандарта в природе столько, что, наверное, можно подобрать
даже такую, которой будут соответствовать 2.4.x-ные Линуховые потоки.
Дело не в стандарте, дело в функционале и управляемости, которая по моему
личному опыту оставляет желать лучшего. Посмотрим, что будет в 2.6?
>История вопроса не имеет никакого отношения к прямоте либо кривизне
>конкретной реализации конкретной функциональности. Исторические ссылки
>позволяют объяснить причину кривизны, но не устраняют её.
Повторяю в третий уж раз: в Linux (это название ядра) не поддерживается концепция multithreading (в определениях SysV/SUN/POSIX/Windows), её там просто нет и не было и всё. :) Поэтому не имеет смысла её обсуждать. Не существует объекта - не существует и степени кривизны оного.>Целью разработчиков было добиться поддержки многопоточности минимальной
>кровью. Они этого добились. Практически всегда лучше плохо, но сегодня,
>чем хорошо, но когда-нибудь. Что касается идей, то IMHO куда как более
>здраво выглядит логическое разделение параллелизма выполнения и
>выделяемых некоей системной единице (процессу) ресурсов.
Опять детский сад - "хорошо"/"плохо". Нет ничего "хорошего" и "плохого". Просто могут быть средства решения одной и той же задачи простые и сложные (и возможно они могут не быть, но это вряд ли). Когда для круга задач есть простые средства решения задач, то инструментарий удобный, в противном случае - неудобных. В частности, для решения многих задач очень удобно применять реализации process-based threads (*BSD, Linux, IRIX), поскольку
классические стандартные библиотеки предоставляют большую гибкость в управлении вводом-выводом,сигналами и прочим для процессов и, следовательно, заимствующих их модель PBT.По поводу логики. IMHO, как раз таки не очень нелогично. Мне кажется логичным, к примеру, что каждый поток управления имеет свой набор обработчиков сигналов, либо он его может разделять по своему желанию, либо он может выбрать, чтобы сигналы посланные любому pbp приходили всем pbp в thread group сразу. Всё это можно в Linux на основе унаследованного интерфейса процессов.
Я начинал серьезно программировать для Linux и познакомился изначально именно с его интерфейсом clone, и меня и по сей день бесит высосанная из пальца концепция POSIX thread.
>Версий оного стандарта в природе столько, что, наверное, можно подобрать
>даже такую, которой будут соответствовать 2.4.x-ные Линуховые потоки.
POSIX Threads принято называть ровно один стандарт IEEE POSIX 1003.1c-1995 (который одновременно является частью более общего ANSI стандарта). Напомню еще раз, что никаких "линуховых потоков" в природе не существует. Грубо говоря, реализация библиотеки POSIX Threads никаким образом не ограничивается ядром (и может даже в какой-то мере не зависеть).>Дело не в стандарте, дело в функционале и управляемости, которая по моему
>личному опыту оставляет желать лучшего.
Примеры по существу, пожалуйста>Посмотрим, что будет в 2.6?
А что Вы там смотреть то собрались? :) Концепция процессов в нем не поменялась (хотя код был немного изменен с целью "расширить" модель процессов Linux до некоего соответствия модели, которую накладно реализовывать в userspace). Смотреть нужно в библиотеки, а не ядро.Всего хорошего.
p.s. слово thread переводится с английского (оригинальный язык этого термина) как "нить" и ни к каким "потокам" никакого отношения не имеет, ни смыслового ни лингвистического.
Как я понял из всего вышесказанного, как всегда у Linux особая дорога,
а NTPL и иже с ним - попытка стандартизации.
Насчет производительности
Я прочитал nptl-draft, там пишут о заоблачной производительности.
У кого нибудь реально уже есть опыт в тестировании nptl?
Насчет функциональности.
Вопрос остался открытым. Существует ли задача, которую принципиально трудно или невозможно решить с моделью lwp.
>Вопрос остался открытым. Существует ли задача, которую принципиально трудно или невозможно решить с моделью lwp.Правильнее было бы поставить вопрос насколько ущербна модель POSIX Threads. И насколько многого нельзя в ней сделать. ;) Linux tasks на порядки гибче.
Как говорил незабвенный Михайло Сергеич, "регламент"!
Так что давайте по-порядку.>Вы вообще в курсе, что для Linux есть с десяток реализаций POSIX Threads,
>начиная с pth и LinuxThreads, заканчивая NGPT и NPTL? В плане интерфейсаВ курсе. Курятником всё это называется и коровником, а никак не ОСью
промышленного уровня. Сие, впрочем лирика.>Давайте определимся для начала что такое "потоки", а потом будем судить о
>том, что такое хорошо и что такое плохо. А то пустой разговор получается.
>:) Ну и дополнительно определимся для чего они нам нужны. :)Пойдём от печки - т.е. "для чего они нам нужны". А нужны они нам в
ситуациях, когда необходимо параллельно обрабатывать клиентские
транзакции по запросам, причём наличествует большое количество общих
структур данных, кои крайне желательно держать в оперативной памяти
(просто из соображений производительности). Можно, конечно, шаманить
с общей памятью, дополнительным клиент-серверным обменом, хранением
всего в БД - но самый элементарный и при этом достаточно элегантный
подход предполагает параллельное наличие множества контекстов выполнения
в одном адресном пространстве. Т.е. общие структуры данных плюс средства
синхронизации. Нити там или не нити, но желательно иметь возможность
масштабирования на SMP-системы, так что чистые user-space системы
отпадают автоматически. Плюс совершенно необходимо обеспечить
высокую переносимость результата.Так что под "потоком" лично мне привычно понимать единицу управления
планированием выполнения в многозадачной ОС, причём некоей совокупности
потоков может выделяться общее адресное пространство, квоты системных
ресурсов, таблицы дескрипторов и т.п.>Повторяю в третий уж раз: в Linux (это название ядра) не поддерживается
>концепция multithreading (в определениях SysV/SUN/POSIX/Windows), её там
>просто нет и не было и всё. :) Поэтому не имеет смысла её обсуждать. Не
>существует объекта - не существует и степени кривизны оного.Я с удовольствием посмотрел бы на индивида, использующего в своей работе
ядро ОС - и ничего, кроме ядра. Не хотелось бы вступать в лингвистические
споры, однако Linux в общем и целом не есть одно лишь ядро, Linux -
совокупность собственно ядра, набора драйверов, библиотек системного
уровня и утилит администрирования. В противном случае любая Linux-
конференция есть коллекция оффтопиков :).>Просто могут быть средства решения одной и той же задачи простые и
>сложные (и возможно они могут не быть, но это вряд ли). Когда для круга
>задач есть простые средства решения задач, то инструментарий удобный, в
>противном случае - неудобных. В частности, для решения многих задач очень
>удобно применять реализации process-based threads (*BSD, Linux, IRIX),
>поскольку классические стандартные библиотеки предоставляют большую
>гибкость в управлении вводом-выводом,сигналами и прочим для процессов и,
>следовательно, заимствующих их модель PBT.Удобство и неудобство, как и кривизна-некривизна, есть очевидным образом
относительные понятия. В вопросе наилучших (наиболее удобных) методов
организации параллельных вычислений мы с вами очевидным образом
расходимся.>Мне кажется логичным, к примеру, что каждый поток управления имеет свой
>набор обработчиков сигналов, либо он его может разделять по своему
>желанию, либо он может выбрать, чтобы сигналы посланные любому pbp
>приходили всем pbp в thread group сразу. Всё это можно в Linux на основе
>унаследованного интерфейса процессов.Управление сигналами есть часть POSIX-спецификации, и на мой взгляд,
описанный там функционал не только не является недостаточным, но и
попросту избыточен. Впрочем, я не слишком большой любитель сигналов
и иже с ними - предпочитаю в аналогичных целях использовать с семафоры, мьютексы и т.п. Кстати, и переносимость кода явно возрастает.>Грубо говоря, реализация библиотеки POSIX Threads никаким образом не
>ограничивается ядром (и может даже в какой-то мере не зависеть).Не может она не ограничиваться, поскольку планировщик выполнения есть
составная часть ядра, и без корректировки оного ядра возможны только
некие действия по преобразованию POSIX-вызовов в существенно отличающиеся
семантикой вызовы ядра. Свистеть-то не надо.>Примеры по существу, пожалуйста
Самое раздражающее явление - периодически возникающие зомбюки
после убиения главного потока. Вполне допускаю, что сие может
быть особенностью конкретного варианта поточной библиотеки,
но толку-то с того? Замена билиотеки, увы, опцией не является.>Концепция процессов в нем не поменялась (хотя код был немного изменен с
>целью "расширить" модель процессов Linux до некоего соответствия модели,
>которую накладно реализовывать в userspace). Смотреть нужно в библиотеки,
>а не ядро.Не просто накладно, просто невозможно полностью обеспечить в оном
"юзерспейсе" хотя бы ту же семантику доставки сигналов потокам.> p.s. слово thread переводится с английского (оригинальный язык этого
>термина) как "нить" и ни к каким "потокам" никакого отношения не имеет,
>ни смыслового ни лингвистического.Лингвистическая беседа получилась. Всё о терминах да о терминах.
Хоть пирогом назови, только в печь не суй.>Правильнее было бы поставить вопрос насколько ущербна модель POSIX
>Threads. И насколько многого нельзя в ней сделать. ;) Linux tasks на
>порядки гибче.Любой стандарт есть соглашение. Любое соглашение налагает набор
ограничений на стороны, его придерживающиеся. Одной из целей определения
стандартов линейки POSIX является обеспечение унификации программных
интерфейсов (и не только) между различными UNIX-подобными (и не только:)
операционными системами. Соответственно, набор вызовов был сформулирован
таким образом, чтобы его можно было реализовать в ОС с совершенно
различными подходами к реализации многозадачности и параллельного
выполнения. Что и подтверждает наличие реализации как под Linux,
так и, скажем, под Solaris. И даже под OpenVMS :)
>В курсе. Курятником всё это называется и коровником, а никак не ОСью
промышленного уровня. Сие, впрочем лирика.С эмоциями, как я погляжу, всё хорошо ;) А как быть с аргументами? ;)
>Пойдём от печки - т.е. "для чего они нам нужны". А нужны
>они нам в
>ситуациях, когда необходимо параллельно обрабатывать клиентские
>транзакции по запросам, причём наличествует большое количество общих
>структур данных, кои крайне желательно держать в оперативной памяти
>(просто из соображений производительности). Можно, конечно, шаманить
>с общей памятью, дополнительным клиент-серверным обменом, хранением
>всего в БД - но самый элементарный и при этом достаточно элегантный
>
>подход предполагает параллельное наличие множества контекстов выполнения
>в одном адресном пространстве. Т.е. общие структуры данных плюс средства
>синхронизации. Нити там или не нити, но желательно иметь возможность
>масштабирования на SMP-системы, так что чистые user-space системы
>отпадают автоматически.
Замечательно. Тут наши представления странным образом совпали. :)>Плюс совершенно необходимо обеспечить высокую переносимость результата.
Начнем с того, что это отдельная постановка задачи. :) И, если сие условие и имеет место, то обычно только после вопросов производительности/функциональности. Ну если в какой-то ситуации вдруг вопрос переносимости стоит рогом, то для этого всегда можно использовать замечательное достижение, называемое условной компиляцией. ;)
>Так что под "потоком" лично мне привычно понимать единицу управления
>планированием выполнения в многозадачной ОС, причём некоей совокупности
>потоков может выделяться общее адресное пространство, квоты системных
>ресурсов, таблицы дескрипторов и т.п.
Ну хорошо. В такой случае по вашему определению интерфейс clone создает полноценные нити - они замечательно подходят под ваши требования. ;)В определениях нитей в стандартах, с которыми я имел счастье ознакомиться, или фирменных реализациях обычно нить документируется как несколько более узкое понятие, для которого специфически определяются последствия fork/exit/exec/signal и прочего, причем единственным и неизменяемым образом ("вот вам модель - а вы уж сами подстраивайте свое приложение под нее").
>Я с удовольствием посмотрел бы на индивида, использующего в своей работе
>ядро ОС - и ничего, кроме ядра. Не хотелось бы вступать в
>лингвистические
>споры, однако Linux в общем и целом не есть одно лишь ядро,
>Linux -
>совокупность собственно ядра, набора драйверов, библиотек системного
>уровня и утилит администрирования. В противном случае любая Linux-
>конференция есть коллекция оффтопиков :).
Я не против такого определения, хотя обычно употребляют "термин дистрибутив Linux", но тогда нужна конкретика в какой же из совокупностей такого добра мы рассматриваем нечто, задокументированное как "threads", но не оправдывающее это звание. ;) Я это всё к тому, что для Linux есть множество библиотек threads и раз уж мы говорим о проблемах, то стоит указывать, что проблема связана с LinuxThreads (или с Pth ну и т.д.).
Опять-таки, когда мы говорим слово "криво" стоит понимать, что та же LinuxThreads не соответствует POSIX Threads, но при этом соответствует своей документации, иначе не совсем ясно о какой "кривизне" идет речь.>Управление сигналами есть часть POSIX-спецификации, и на мой взгляд,
>описанный там функционал не только не является недостаточным, но и
>попросту избыточен.
Ну давайте рассмотрим простой пример. Есть у нас асинхронный ввод/вывод (не тот, который AIO, а тот, который overlapped I/O), нить A1 делает запрос на чтение из сокета A, окончание должно придти сигналом SIGIO в нить A2, нить B1 делает запрос на чтение из сокета B, окончание должно придти сигналом SIGIO в нить B2.Возможно ли такое в POSIX Threads? (это к слову о перенасыщенности). Ну или в чьих-нибудь фирменных threads? :)
>Впрочем, я не слишком большой любитель сигналов
>и иже с ними - предпочитаю в аналогичных целях использовать с семафоры,
>мьютексы и т.п. Кстати, и переносимость кода явно возрастает.
Ну зачастую сигналы нам даны свыше, то бишь ядреные сигналы. Использовать сигналы в качестве IPC - это и правда не очень здоровая идея. ;)>Не может она не ограничиваться, поскольку планировщик выполнения есть
>составная часть ядра, и без корректировки оного ядра возможны только
>некие действия по преобразованию POSIX-вызовов в существенно отличающиеся
>семантикой вызовы ядра. Свистеть-то не надо.
А всё было так хорошо... ;) И как же по-вашему реализованы threads в ОС, которые не поддерживают этой концепции на уровне ядра? Правильно - планировщик реализован на userspace уровне, точно так же можно полностью реализовать POSIX-compliant IPC и прочие фенечки, хотя это и проще делать когда ядро поддерживает прозрачный интерфейс для всего этого ;)>Самое раздражающее явление - периодически возникающие зомбюки
>после убиения главного потока. Вполне допускаю, что сие может
>быть особенностью конкретного варианта поточной библиотеки,
>но толку-то с того? Замена билиотеки, увы, опцией не является.
Есть такое явление в LinuxThreads. IMHO сие возможно только если manager thread не ловит SIGCLD (что достаточно странно :) поставил зарубку - посмотреть ;)). А насчет замены - что мешает статической компоновке с нужной библиотекой threads? ;) Правда, что касается POSIX Threads, то я не исключаю возможности того, что для Linux 100% совместимой с этим интерфейсом библиотеки попросту не существует (что там насчет Pth и pthreads? ;)).>Не просто накладно, просто невозможно полностью обеспечить в оном
>"юзерспейсе" хотя бы ту же семантику доставки сигналов потокам.
Надо подумать :) Интересная задача, кстати (зарубка N2).
Вообще, проблему я пока вижу только с "неловящимися" сигналами (SIGKILL, SIGSTOP).>Любой стандарт есть соглашение. Любое соглашение налагает набор
>ограничений на стороны, его придерживающиеся. Одной из целей определения
>стандартов линейки POSIX является обеспечение унификации программных
>интерфейсов (и не только) между различными UNIX-подобными (и не только:)
>операционными системами.
Унификация - это да. Это цель любого стандарта. Только важно понимать на какие жертвы приходится идти ради этой самой унификации. ;)>Соответственно, набор вызовов был сформулирован
>таким образом, чтобы его можно было реализовать в ОС с совершенно
>различными подходами к реализации многозадачности и параллельного
>выполнения. Что и подтверждает наличие реализации как под Linux,
>так и, скажем, под Solaris. И даже под OpenVMS :)
>Замечательно. Тут наши представления странным образом совпали. :)
>Свершилось чудо :)
>Начнем с того, что это отдельная постановка задачи. :) И, если сие
>условие и имеет место, то обычно только после вопросов
>производительности/функциональности. Ну
>если в какой-то ситуации вдруг вопрос переносимости стоит рогом, то для
>этого всегда можно использовать замечательное достижение, называемое
>условной компиляцией. ;)Указанное достижение при интенсивном применении в сильно насыщенном
прикладной логикой коде имеет ещё одно название - интеллектуальный
геморрой ;-)>Ну хорошо. В такой случае по вашему определению интерфейс clone создает
>полноценные нити - они замечательно подходят под ваши требования. ;)
>Полноценные там они или нет, но (1) свои, особенные и сугубо Линуксовые
(что вполне нормально для низкоуровневого системного кода!) и (2)
приводящие к некоему чисто эстетически неприятному последствию -
плодящимся экземплярам процесса, причём понять "а кто из них главный"
можно исключительно по принципу "выбирай минимальный pid из группы
похожих друг на друга процессов".>В определениях нитей в стандартах, с которыми я имел счастье
>ознакомиться, или фирменных реализациях обычно нить документируется как
>несколько более узкое понятие, для которого специфически определяются
>последствия fork/exit/exec/signal и прочего, причем единственным и
>неизменяемым образом ("вот вам модель - а вы уж сами подстраивайте свое
>приложение под нее").
>Всё упирается в вопрос - а что, указанная семантика создаёт некие
проблемы? Да, например, при выполнении fork() в Solaris копируется
лишь поток, оный fork() вызвавший. Но много ли современных
(многопоточных!) программ используют fork() иначе как в комбинации
с последующим exec()?>Опять-таки, когда мы говорим слово "криво" стоит понимать, что та же
>LinuxThreads не соответствует POSIX Threads, но при этом соответствует
>своей документации, иначе не совсем ясно о какой "кривизне" идет речь.
>Что автоматически приводит к появлению дополнительных "уровней абстракции
от ОС", хитроумных библиотек, корректирующих семантику, уйме директив
условной компиляции etc etc etc. Всё это суровая правда жизни, но нигде
не указано, что суровой правде жизни обязательно нужно радоваться :)>Ну давайте рассмотрим простой пример. Есть у нас асинхронный ввод/вывод
>(не тот, который AIO, а тот, который overlapped I/O), нить A1 делает
>запрос на чтение из сокета A, окончание должно придти сигналом SIGIO в
>нить A2, нить B1 делает запрос на чтение из сокета B,
>окончание должно придти сигналом SIGIO в нить B2.
>Пример из разряда: есть у нас расчёска и свободная нога (руки заняты),
требуется причесать шевелюру на идеальный пробор. Не в обиду автору.>Возможно ли такое в POSIX Threads? (это к слову о перенасыщенности). Ну
>или в чьих-нибудь фирменных threads? :)
>В Солярных потоках точно можно. Там вообще чёрт ногу сломит, если в недра
лезть. Прелесть вся в том, что никто не заставляет это делать - хватает
тебе POSIX-семантики - причём точной и аккуратно реализованной - ну так
сиди себе и радуйся жизни, не изобретая лишних проблем на больную голову.>А всё было так хорошо... ;) И как же по-вашему реализованы threads
>в ОС, которые не поддерживают этой концепции на уровне ядра? Правильно
>- планировщик реализован на userspace уровне, точно так же можно
>полностью реализовать POSIX-compliant IPC и прочие фенечки, хотя это и
>проще делать когда ядро поддерживает прозрачный интерфейс для всего
>этого ;)Мнда, только результат будет, мягко говоря, не очень быстрый.
И IMHO не очень стабильный. Мы же про реальный мир толкуем, не про
академические вопросы алгоритмической реализуемости :)>А насчет замены - что мешает статической компоновке с нужной
>библиотекой threads? ;)Динамическая линковка всего остального. Плюс использование
поточных функций сразу в нескольких модулях, по технологическим
причинам реализуемых как динамические библиотеки.>Правда, что касается POSIX Threads, то я не исключаю возможности того,
>что для Linux 100% совместимой с этим интерфейсом
>библиотеки попросту не существует (что там насчет Pth и pthreads? ;)).
>В сём вопросе я отнюдь не съел собаки, однако должен заметить, что в
плане деталей реализации стандарта и у "фирмачей" бывают огрехи.>Надо подумать :) Интересная задача, кстати (зарубка N2).
>Вообще, проблему я пока вижу только с "неловящимися" сигналами
>(SIGKILL, SIGSTOP).
>Проблема ещё и с тем, а кому именно из коллекции потоков доставлять
пойманный "подарочек"?
Кстати, немаскируемые сигналы и доставлять-то не нужно. Вот именно
здесь ядрышко должно сказать своё большое и веское слово, прикончив не
только родителя (сиречь главный поток), но и всех его деток. IMHO,
зомбюки могут ещё и отсюда набегать.>Унификация - это да. Это цель любого стандарта. Только важно понимать на
>какие жертвы приходится идти ради этой самой унификации. ;)
>Всё как обычно - допустимость той или иной жертвы лежит на совести
стороны, принимающей либо отвергающей соглашение :)Вообще забавный диалог получился. Но дальше с флеймом надо, наверное,
завязывать.Thanks и проч.
>
>(что вполне нормально для низкоуровневого системного кода!) и (2)
>приводящие к некоему чисто эстетически неприятному последствию -
>плодящимся экземплярам процесса, причём понять "а кто из них главный"
>можно исключительно по принципу "выбирай минимальный pid из группы
>похожих друг на друга процессов".pstree -alp
>Как я понял из всего вышесказанного, как всегда у Linux особая дорога,а я понял, что у тебя особый взгляд на Linux и его дорогу. И что?
Какое отношение к теме?/poige
--
http://www.i.morning.ru/~poige/
>>Как я понял из всего вышесказанного, как всегда у Linux особая дорога,
>
>а я понял, что у тебя особый взгляд на Linux и его
>дорогу. И что?
>Какое отношение к теме?
>Вы либо флеймер, либо начинающий модератор.
PS: Если я считаю что у Linux свой собственный путь, это совсем не означает что я считаю его плохим.
>>>Как я понял из всего вышесказанного, как всегда у Linux особая дорога,
>>
>>а я понял, что у тебя особый взгляд на Linux и его
>>дорогу. И что?
>>Какое отношение к теме?
>>
>
>Вы либо флеймер, либо начинающий модератор.одно другому не мешает.
>
>PS: Если я считаю что у Linux свой собственный путь, это совсем
>не означает что я считаю его плохим.чтобы так считать, нужно, чтобы это было обоснованно. Необоснованное неверное суждение ничем не лучше.
/poige
--
http://www.i.morning.ru/~poige/
если суждение небоснованное, то почему оно у тебя уже сразу неверное ? :) ты же не потрудился этого объяснить, так что это тот же выстрел в воздух.ЗЫ. Вот замечено мной, что люди, указывающие свой урл в каждом сообщении, обычно говорят "ниочем". это реклама такая... :)
/poige
--
http://www.I.morning.ru/~poige/ (там все сказано).
в таком случае, думаю тебе не стоит даже напрягаться и писать какие-то еще слова в обсуждениях. указал урл - и хватит. по ссылке же все твои мысли по любому вопросу :)ЗЫ. не все пуп земли, что торчит высоко.
>в таком случае, думаю тебе не стоит даже напрягаться и писать какие-то
>еще слова в обсуждениях. указал урл - и хватит. по
>ссылке же все твои мысли по любому вопросу :)Это с чего ты так надумал, мысли что-ли в голове удалось отыскать? :-)
Ты нашел неправильные мысли у себя, и тебе можно поставить двойку. ;-)
>
>ЗЫ. не все пуп земли, что торчит высоко.Молодец, эта мысль уже правильнее. Осталось тебе только ее применить к себе.
/poige
--
http://www.i.morning.ru/~poige/
ведение спора в стиле "дурак - сам дурак" - это первый признак несформировавшейся личности, рьяно стремящейся самоутвердиться :) продолжай дальше, это достаточно забавно наблюдать, как ты стремишься все оценить и всех наставить на путь истинный. рости большой :)
>ведение спора в стиле "дурак - сам дурак" - это первый признак
>несформировавшейся личности, рьяно стремящейся самоутвердиться :) продолжайСкороспелое суждение (опять двойка, картина маслом). :-)
Попробуй считать, что я мастер, и владею разными стилями.
Применяю по принципу "что знаю, И что подходит", к слову,
ровно как и операционнки, поэтому юзаю почти все основное
UNIX-like, а не ору Linux suxxx. :-)> дальше, это достаточно забавно
>наблюдать, как ты стремишься все оценить и всех наставить на путь
>истинный. рости большой :)о, вот тут, типа, намек на несформированность. Я в процессе.
Спасибо за заботу, надеюсь, что вам помогут. Хотя спецов крайне
мало в любой области./poige
--
http://www.i.morning.ru/~poige/
>Вопрос остался открытым. Существует ли задача, которую принципиально трудно или невозможно решить
>с моделью lwp.
Вопрос надо ставить по другому: Какие задачи с помощью каких средств удобнее решать. С помощью lwp например удобнее писать сервиса a la SQL сервер или вообще любой сервер очереди.
>>Дело не в стандарте, дело в функционале и управляемости, которая по моему
>>личному опыту оставляет желать лучшего.
>Примеры по существу, пожалуйстаПожалуйста ;-).
Читать здесь:
http://www.shelek.com/club/viewart.php?id=82
- перевод крайне плохого качества, что компенсируется содержанием.
>Пожалуйста ;-).
>Читать здесь:
>http://www.shelek.com/club/viewart.php?id=82
>- перевод крайне плохого качества, что компенсируется содержанием.
Ну и зачем Вы дали ссылку на статью по несоответствию LinuxThreads POSIX?
Речь то шла не об этом (читайте еще разок всё, что написано выше - я говорил о программировании с Linux семантикой vwp).
Кроме того, в этой статье, которую я уже давно прокомментировал на соответствующем ресурсы слишком много ляпов, чтобы ее рассматривать всерьез.
>>Для начала нужно определиться с тем, что вы называете нитями, а потом
>>уже и смотреть что криво, а что не криво.
>>
>>Начнем с того, что был UNIX на PDP и были на нем
>>процессы и всё было хорошо. Со временем его портировали на большие
>
>История вопроса не имеет никакого отношения к прямоте либо кривизне
>конкретной реализации конкретной функциональности. Исторические ссылки
>позволяют объяснить причину кривизны, но не устраняют её.
>
а вот нудить не нужно. Все в тему./poige
--
http://www.i.morning.ru/~poige/
>Версий оного стандарта в природе столько, что, наверное, можно подобрать
>даже такую, которой будут соответствовать 2.4.x-ные Линуховые потоки.
>Дело не в стандарте, дело в функционале и управляемости, которая по моему
>Ничего подобного, POSIX - несколько стандартов (4-5-6), каждый из которых охватывает только свои аспекты, напр.: POSIX 1 - основной API, POSIX 1003b - расширени реального времени и т.д.
Так что ничего, что соответствовало бы "линуховым потокам" - подобрать не удасться ;-).
На сегодня в UNIX-like OS уже складывается отношение, что каждая OS ровно в той степени, в которой она соответствует POSIX и/или UNIX98.
А в этом смысле - Linux thread - очень большое расхождение с POSIX, хотя бы потому, что и потоки и процессы создаются clone(), и thread имеют различные pid.
>На сегодня в UNIX-like OS уже складывается отношение, что каждая OS ровно
>в той степени, в которой она соответствует POSIX и/или UNIX98.Обладатель торговой марки UNIX не определяет "степень like" - тут или да или нет. Насколько я помню, сертифицированы Solaris, AIX и SCO UNIX. Остальные просто напросто не пройдут тесты, поскольку не удовлетворяют SuS в должной степени.
>А в этом смысле - Linux thread - очень большое расхождение с
>POSIX, хотя бы потому, что и потоки и процессы создаются clone(),
>и thread имеют различные pid.У Вас те же проблемы, что и у первого оратора. Вы не понимаете где разница между епархией ядра и нитевой библиотеки (рискну предположить, что даже не представляете архитектуры планирования Linux, иначе бы давно уже проассоциировали thread group id(AKA tgid) с process id (aka pid)).
Всего наилучшего.
>У Вас те же проблемы, что и у первого оратора. Вы не
>понимаете где разница между епархией ядра и нитевой библиотеки (рискну предположить,
>что даже не представляете архитектуры планирования Linux, иначе бы давно уже
>проассоциировали thread group id(AKA tgid) с process id (aka pid)).У меня как раз проблем нет...
И с чего это вы решили, что можете заключать, кто и что "не понимает"?
Я годами использую POSIX модель thread в своих кодах для realtime & embedded оборудования, и как раз здесь, в стандартизованной модели - проблем нет...
А "архитектуру планирования Linux" я и вправду - "даже не представляю"... она мне нафиг неинтересна, до тех пор, пока она будет "самопальщиной"!
>А "архитектуру планирования Linux" я и вправду - "даже не представляю"...
>она мне нафиг неинтересна, до тех пор, пока она будет "самопальщиной"!Вот нашелся разумный человек. А то наплодили кудес...
Суровый признак разумности. Я напомню, то, что вы позабыли -- UNIX (R) это тоже самопальщина. Ровно как и С, и, уж тем более, C++. В общем, "непомнящие прошлого обречены повторять его".P. S. Holly Wars обрели новый плацдарм.
/poige
--
http://www.i.morning.ru/~poige/
>Суровый признак разумности. Я напомню, то, что вы позабыли -- UNIX (R)
>это тоже самопальщина. Ровно как и С, и, уж тем более,
>C++.
Я не имел умысла никого (Linux) ущемлять в пользу другим UNIX-like...
Но в в нём (нверное от "молодости") - ещё много неупорядоченности: особенно в части шедулирования, процессов, потоков. Это уже всё обкатано в других UNIX, и прописано в POSIX 1003c, 1003b, сейчас должен быть 1003g и
The Open Group Base Specifications Issue 6 IEEE Std 1003.1-2001 (http://www.kuzbass.ru:8083/docs/sus2/mindex.html) - как раз это редкий случай, когда стандарты идут "вперёд" реализаций...
Так вот - моё замечание относилось только к тому, что ... "я лучше пока подожду, пока в Linux это устаканится" - и вот уж что "не надо" - так это обвирять меня в религиозных войнах!
>Обладатель торговой марки UNIX не определяет "степень like" - тут или да
>или нет. Насколько я помню, сертифицированы Solaris, AIX и SCO UNIX.
>Остальные просто напросто не пройдут тесты, поскольку не удовлетворяют
>SuS в должной степени.Фигня это. И не нужно смущать дезинформацией неокрепшие умы:
- "Обладатель торговой марки" - это кто? SCO?
- так вот, не так давно закончилась тяжба, в которой Open Group (известный ранее как X-консорциум) доказал, что даже марка UNIX принадлежит 2-м субъектам в равной мере SCO & Open Group. Почитать можно здесь, например:
http://www.kuzbass.ru:8083/docs/sus2/mindex.html
- и с какой это стати, и на каком основании SCO вообще вправе "сертифицировать" нечто, на соответствие SCO UNIX? На том только основании, что им ЭТО перепало после многочисленных перепасовок, да и то не первой свежести?
- и потом: "сертифицированы" - каким документом? Ссылки в студию!
- да и перечисленные вами "Solaris, AIX и SCO UNIX" - это всё линия SVR4 - а что, вся линия Беркли, в которой существенного для UNIX было сделано во много крат более - так её что, не существует?
- а вот стандарты Open Group, они же известны как UNIX95, UNIX98 - и очень плотно взаимодействуют при разработках с POSIX - вот они являются определяющим местом "что есть UNIX".
- и именно стандартизация POSIX/UNIX98 и делают мир UNIX-like тем, чем он есть, с переносимостью и возможностью портирования кода...
- и единственное интересное место во всей истории развития Linux - это то, что они во всём следовали традициям и стандартам UNIX (утилиты, API...), которые к тому времени уже да-а-а-авно устоялись - следовали, даже "наступая на горло своей песне"...
- следовали бы они какой-нибудь BeOS да ещё с потугами сделать "самую лучшую из OS"... где бы сейчас был тот Linux?
забывают о проблемах, им свойственных.>Со временем его портировали на большие
>машины и стали использовать в серьезных приложениях, по ходу дела
>решили, что лишние переключения контекста MMU вроде как не очень хороши,
>потому как ощутимо тормозят многопроцессное приложение/систему. И решили
>делить адресное пространство
>между потоками управления.Существует в природе такая проблема, как проблема когерентностей кэшей.
Она имеет место в многопроцессорных системах и, в частности,
когда о ней говорят производители железа, она оценивается как
весьма серьезная в том смысле, что решается ценой существенного overhead.
Проблема решается аппаратным путем и, как правило, многие программисты о
ее существовании даже не подозревают.Чтобы далеко в теорию не заплывать, приведем пример:
Пусть мы имеем 4 процессора. На каждом работает по одному потоку нашей программы.
Адресное пространство -- единое, следовательно, переменные и структуры
данных -- тоже. Как мы помним, процессор работает с данными, находящимися
в его кэше.Когда поток пытается обновить значение какой-либо переменной (или структуры),
с которой он работает, необходимо определить, присутствует ли ее значение
в кэшах других процессоров и, если оно присутствует, его необходимо синхронизировать.
Весь этот процесс и называется "проблемой когерентности кэшей".Когда одновременно работают несколько процессов -- проблемы когерентности не
возникает по понятным причинам.
На мой взгляд, именно проблема когерентности и давала основную пищу для
противников многопоточных архитектур. Но эти дебаты, насколько я понимаю, для
многих неизвестны или уже не актуальны.Теперь о том, для чего это я написал:
Потому, что считаю необходимым прояснить причину возникновения потоков.
А именно, причина заключается не в том, что процесы переключать медленнее,
а в том, что межпоточные взаимодействия программировать легче, т.к. имеет
место общая память и размер ее (условно) не ограничен (не нужно связываться с
какими-либо механизмами IPC типа Shared Memory).Кроме этого, резюмируя, хочу сказать, что вполне вероятна ситуация,
когда многопроцессные системы в конкретных частных случаях будут более
производительными, чем их многопоточные аналоги, всилу вышеуказанной проблемы.
>Когда одновременно работают несколько процессов -- проблемы
>когерентности не возникает по понятным причинам.Вот здесь ... об понятных причинах - подробнее, пожалуйста.
>а в том, что межпоточные взаимодействия программировать легче, т.к. имеет
>место общая память и размер ее (условно) не ограничен (не нужно >связываться с какими-либо механизмами IPC типа Shared Memory).Как я понимаю, проблемма некогерентности кэшей возникает только на тех небольшим областям данных, которые совместно используются thread для обмена или синхронизации...
С другой стороны - для всех областей памяти, используемых IPC при межпроцессном взаимодействии (состояние именованного семафора, или области той же shared memory) - будут в той же мере возникать эффекты некогерентности кэшей. Или нет?
>>Когда одновременно работают несколько процессов -- проблемы
>>когерентности не возникает по понятным причинам.
>
>Вот здесь ... об понятных причинах - подробнее, пожалуйста.Разные адресные пространства -- разные экземпляры переменных.
Их нет неободимости синхронизировать.>
>>а в том, что межпоточные взаимодействия программировать легче, т.к. имеет
>>место общая память и размер ее (условно) не ограничен (не нужно >связываться с какими-либо механизмами IPC типа Shared Memory).
>
>Как я понимаю, проблемма некогерентности кэшей возникает только на тех небольшим областям
>данных, которые совместно используются thread для обмена или синхронизации...Не только: она возникает для всех потенциально совместно используемых глобальных (в смысле те, которые не в стеке) структур/переменных, которые и являются источником трафика по шине, обеспечивающей эту когерентность.
Более детально механизмы разрешения проблемы когерентности описаны в популярной литературе к какой-нить ccNUMA (Cache-Coherent Non-Uniform Memory Access). ccNUMA является логическим продолжением SMP,
только проблема когерентности проявляется там еще серьезнее (она в название даже вынесена).>С другой стороны - для всех областей памяти, используемых IPC при межпроцессном
>взаимодействии (состояние именованного семафора, или области той же shared memory) -
>будут в той же мере возникать эффекты некогерентности кэшей. Или нет?
>Самафор в SMP -- это скорее всего программная обертка функциональности, предоставляемой железкой. По этому тут о какой-то когерентности говорить можно, но она не будет иметь ничего общего с тем, о чем мы говорили изначально. Что касается общей памяти -- то ответ интуитивно понятен: когерентность быть должна, т.к. реально существует несколько копий одних и тех же данных -- 1-я в ОП, остальные в кэшах процессоров.
>Разные адресные пространства -- разные экземпляры переменных.
>Их нет неободимости синхронизировать.
Кроме тех областей, которые используются для IPC.>Не только: она возникает для всех потенциально совместно используемых >глобальных (в смысле те, которые не в стеке) структур/переменных,
>которые и являются источником трафика по шине, обеспечивающей эту
>когерентность.
thread-ы, в свою очередь могут аккуратно использовать технику экземпляров данных - всё, что связано с pthread_key_*()...Т.е. проблемы некогерентности в SMP могут возникать как в тех, так и в других случаях...
С другой стороны - в некоторых ситуациях fork()/pthread_create() реализации по производительности, точнее даже по "времени латентности" (что ещё хуже - именно в те короткие интервалы, когда от них и ожидают активности) - могут отличаться на 1-2-3 порядка!
Я как-то такой тестик сделал... он "разошёлся" по Internet, вот 1 из URL - захотите - посмотрите: http://www.winsov.com/ci003.php.P.S.
>Самафор в SMP -- это скорее всего программная обертка функциональности, >предоставляемой железкой. По этому тут о какой-то когерентности говорить >можно, но она не будет иметь ничего общего с тем, о чем мы говорили
>изначально.
Зачем - простейшие синхронизаторы: мютекс + семафор - вполне достаточно переменной, над которой выполняются неделимые операции INC/DEC - только сделайте её доступной процессам/потокам.
>Кроме тех областей, которые используются для IPC.это да, но часто ли IPC используются?
я-то про пользовательские данные толкую, а их несоизмеримо больше.>
>>Не только: она возникает для всех потенциально совместно используемых >глобальных (в смысле те, которые не в стеке) структур/переменных,
>>которые и являются источником трафика по шине, обеспечивающей эту
>>когерентность.
>thread-ы, в свою очередь могут аккуратно использовать технику экземпляров данных - всё,
>что связано с pthread_key_*()...опять упераемся в то, что сделать можно все;)
речь-то не о том, что нельзя, а о том -- в каком случае, когда и, главное, какой ценой;)>
>Т.е. проблемы некогерентности в SMP могут возникать как в тех, так и
>в других случаях...от этой проблемы никуда не деться, т.к. она точно также справедлива и для данных ядра ;)
>
>С другой стороны - в некоторых ситуациях fork()/pthread_create() реализации по производительности, точнее
>даже по "времени латентности" (что ещё хуже - именно в те
>короткие интервалы, когда от них и ожидают активности) - могут отличаться
>на 1-2-3 порядка!
>Я как-то такой тестик сделал... он "разошёлся" по Internet, вот 1 из
>URL - захотите - посмотрите: http://www.winsov.com/ci003.php.интересный тестик, я его давно видел. спасибо за то, что не поленились его составить и, главное, опубликовать ;)
но он, насколько я понял, для однопроцессорной системы. что, все-таки снижает его полезность для многопроцессорных.>
>P.S.
>>Самафор в SMP -- это скорее всего программная обертка функциональности, >предоставляемой железкой. По этому тут о какой-то когерентности говорить >можно, но она не будет иметь ничего общего с тем, о чем мы говорили
>>изначально.
>Зачем - простейшие синхронизаторы: мютекс + семафор - вполне достаточно переменной, над
>которой выполняются неделимые операции INC/DEC - только сделайте её доступной процессам/потокам.
>операции INC/DEC недостаточно в многопроцессорной системе. категорически недостаточно. Дийкстра придумал семафор, основанный на INC/DEC для одного процессора -- центрального. но когда их несколько -- ситуация радикально и необратимо меняется. в SMP нужны инструменты синхронизации, поддерживаемые аппаратно, иначе они будут работать категорически плохо (читай медленно).
ЗЫ: если кому интересно, в прошлом году вышла замачательная книга отца и сына Воеводиных под названием "параллельные вычисления". рекомендую.
>интересный тестик, я его давно видел. спасибо за то, что не поленились
>его составить и, главное, опубликовать ;)
>но он, насколько я понял, для однопроцессорной системы. что, все-таки
>снижает его полезность для многопроцессорных.
Естественно! - это никак не соотносилось с SMP:
- во-первых, это писалось чисто для программистов, "какими способами это сделать", а потом уже оттестировалось, и результаты мне оказались совсем не очевидными...
- во-вторых... SMP просто нужно иметь как постоянный рабочий инструмент, это - совсем отдельная и очень интересная стезя...>ЗЫ: если кому интересно, в прошлом году вышла замачательная книга отца и
>сына Воеводиных под названием "параллельные вычисления". рекомендую.
А подробнее нельзя указать? может URL где есть размещения, или библиографические данные бумажного издания?
>Естественно! - это никак не соотносилось с SMP:
>- во-первых, это писалось чисто для программистов, "какими способами это сделать", а
>потом уже оттестировалось, и результаты мне оказались совсем не очевидными...
>- во-вторых... SMP просто нужно иметь как постоянный рабочий инструмент, это -
>совсем отдельная и очень интересная стезя...о том и речь! мы, видимо, о разных системах говорили: я о когерентности кэшей в многопроцессорной системе, а вы, по видимому, интерполировали отсутствие сей проблемы в случае с единственным процессором на многопроцессорную архитектуру.
>
>>ЗЫ: если кому интересно, в прошлом году вышла замачательная книга отца и
>>сына Воеводиных под названием "параллельные вычисления". рекомендую.
>А подробнее нельзя указать? может URL где есть размещения, или библиографические данные
>бумажного издания?я ее купил на Озоне.
узнал о ней из анонса на parallel.ru. картинка прямо на первой странице.для украины см. зеркало kiev.parallel.ru.
пишу с работы, а книжка -- дома. других реквизитов не помню.
>Здравствуйте.
>Постоянно слышу в различных статьях и форумах о том что потоки в
>линукс реализованы криво. Последнее время заинтересовался системным
>программированием, интересует в чем же всё-таки их слабость.
>Хотелось бы также получить рекомендации в выборе литературы для
>правильного изучения ОС. В данный момент подумываю купить "Современные
>операционные системы" Таненбаума.После некоторого периода "реконструкции" (которя ему в пользу не пошла :-() - восстановил работу форум по QNX: http://qnx.org.ru/forum .
Почему я об этом - здесь? Потому, что для QNX, как одного из UNIX, и в высшей степени совместимой с POSIX OS - характерно как раз очень интенсивоное использование параллелизмов. Там на форуме есть достаточно много обсуждений и оригинальных статей, посвящённых POSIX thread модели.