Я про 2.4. О тредах знает ТОЛЬКО процесс. Ядро о них ничего не знает. И шедулит оно только процессы. Все остальное - на уровне библиотеки. Процесс как таковой даже тела почти не имеет (я имею ввиду каких-то описательных структур). Если у ядра есть таблица процессов, то таблицы потоков у него нет. В 2.6, может, по другому (хотя я, если честно, в этом сомневаюсь).

Не сомневайтесь, а лучше посмотрите исходники библиотек и ядра, а еще почитайте книжку, ссылку на которую я приводил ранее в этой теме.

Кроме того, для осознания сути потоков в ядрах 2.4 и 2.6 советую почитать:
http://linuxdevices.com/articles/AT6753699732.html
и
http://www-128.ibm.com/developerworks/linu...-threading.html

Робяты ... POSIX, 1003b требует, чтобы для атрибутов потока могли быть установлены режимы решедулирования:
int pthread_attr_setscope( pthread_attr_t* attr, PTHREAD_SCOPE_SYSTEM );
или
int pthread_attr_setscope( pthread_attr_t* attr, PTHREAD_SCOPE_PROCESS );
- эти 2 и никаких больше: PTHREAD_SCOPE_SYSTEM (в рамках системы) и PTHREAD_SCOPE_PROCESS (в рамках заключающих потоки процессов) ... но 2-й способ ни в одной UNIX-like OS толком не реализован, а в Rationale к POSIX - выражается робкое сомнение как его можно реализовать вообще...
И в Linux, как системе претендующей на POSIX OS, только более "колхозной" - ничего другого быть не может, долгое время путаницу вносил механизм создания через clone, когда потоки и процессы создавались однотипно, "заказывая" им перечень атрибутов: немножко беременный / немножко не беременный ...
Из POSIX определения уже понятно, что именно только и исключительно потоки и могут быть объектом решедулирования. И поэтому потоки просто не могут не быть объектами ядра ... Иллюзию путаницы здесь создаёт то, что всякий процесс, хотите вы того или нет , имеет как минимум 1 поток - главный, main() - вот он у вас и решедулируется под видом процесса. А процесс - это просто мёртвая статическая оболочка над потоком, служащая менеджеру процессов для занесения туда статистической и учётной информации, типа "занимаемое процессорное время"... В других ОС, например QNX или Plan9 - это гораздо отчётливее видно, в Linux это смазывается его монолитным макроядром .

Кстати, раз пошла такая пьянка, может подскажет кто - что есть почитать на тему правильного написания программ с использованием всех имеющихся механизмов.
Просто очень много литературы о том как создать механизм (т.е. драйвер), как работать с сокетами, тридами, синхронным и асинхронным I/O, с fork/exec и т.д. А о том что в каких местах применять - информации не нашел. Приходится пользоваться какими-то обрывочными сведениями.

Например, как решается задача планировки в user space? Допустим имеется последовательная шина, на которой висит несколько устройств с разным приоритетом опроса. Есть ли какие-то штатные средства для создания очереди запросов, возможно с различной приоритетностью и раздачи результатов тем кто ожидает результатов? Или как всегда все надо делать самому? Как правильно такие задачи декомпозировать в среде Linux?

Может есть что-то в качестве хорошего рабочего примера?

1. посмотрите для начала:
http://www.books.ru/shop/books/357604
- и не потому, что это чем-то лучше, чем другие источники - но это результаты экспериментирования в коде, и коды эти все приведены, и результаты там совсем не ожидаемые и даже временами неожиданные - вы можете всё это повторить в своей любимой ОС и проанализировать выявленные артефакты...

2. ... и конечно - 2 Стивенса :
У. Стивенс "UNIX: взаимодействие процессов" - СПб.: Питер, 2002 - 576 стр.
У. Стивенс "UNIX: разработка сетевых приложений" - СПб.: Питер, 2003 - 1088 стр.
(при чём здесь сетевые приложения? - а при том, что основная доля асинхронностей и параллелизмов "вылезает" именно в сетевых приложениях).


3. параллельность - это одно, а параллельность при вмешательстве приоритетов - это уже совсем другое; 1-е как нельзя лучше (даже исчерпывающе) проанализировано Э.Дейкстра и Хоаром (их публикации и результаты вы легко найдёте) - 2-е ... при наличии приоритетов очень сложно создать формальную модель (это не я оцениваю, а те кто работают в этой области) - посмотрите в сторону частотно-монотонной диспетчеризации, вот 2 перевода здесь:
http://qnxclub.net/modules.php?name=Conten...wpage&pid=7
(2 самых верхних ).

Здесь путаницу вносит видимо несколько реализаций тредов, которые имеются в linux'е - linuxthreads (2.4) и nptl (2.4/2.6) - счедулинг кажной треды или группового процесса присутствует о обеих реализациях. Только в первой он сделан в user-space с помощью дополнительной треды, со всеми вытекающими "особенностями", что видимо и вызывает справедливые нарекания программеров

А если у тебя внутри процесса несколько потоков (а не один main), кто их будет шедулить: библиотека или ядро (я имею ввиду планировщик ядра)? Я говорю - библиотека, никак не ядро. Слабо себе представляю в linux приоритет потоков не в рамках одного процесса. А ведь приоритет является основой шедулинга (пусть и условной).



Чего за nptl? Можно поподробнее?

Сообщение отредактировал InvisibleFed - Jan 22 2007, 10:57

В нормальной реализации потоков (я не знаю, до какой степени уже "нормальная" реализация в Linux - некоторое время не смотрел в эту сторону, но она всё больше сдвигается в сторону "нормальной" ) - "если у тебя внутри процесса несколько потоков" - то шедулить их будет, конечно же - ядро , потому что единицей шеулирования является поток, а вовсе не процесс, как раз о процессе ядро может и вообще ничего не знать: это знане нужно менеджеру процессов для запуска, завершения и корректировки статистики в ходе выполнения, не более. А вот как раз приоритет выполнения - он является состаной частью атрибутной записи потока - pthread_attr_t. Да кроме всего прочего, этот приоритет (и сделать это может только ядро ОС) время от времени системе (хорошей системе ) придётся изменять без вашего ведома: ввеох-вниз, так что вы этого и не заметите без специальных усилий - при чисто статических приоритетах вы нарвётесь на инверсию пиоритетов (при 3-х и более процессов/потоков) и ... тю-тю ...

P.S. "нормальную" реализацию потоков, о которой я говорил выше, которая полностью соответствует POSIX реального времени - можем наблюдать в QNX ... рассмотревши её там - можно переносить аналогии и на Linux.

Зесь уже очень верно заметили раньше:

- на предмет того, что без MMU и изолированого адресного пространства - например в MS-DOS - различать процессы и потоки невозможно, это одно и то же; как, в частности, и обработчики IRQ, кстати, которые и есть прародителем-моделью потока... Хотя и не одно и то же - текстуально, в коде: переменные-объекты потоков находятся в общем поле видимости, но если отбросить это малое различие, то потоки/процессы MS-DOS могли бы разделять переменные по фиксированным адресам, например - вот эта "видимость" и есть главной причиной "придумывания" потоков ... а не время переключения контекста: о разительной разнице времён переключения контекстов потоков/процессов - это красивая народная легенда ... преподаватели ВУЗов её часто "доносят" студентам - поскольку "на хлопський розум" это так и выглядит, а руками преподаватели, обычно, свои предположения не перепроверяют ...
Так же неверно и предположение: "Процессы и потоки выдумка Linux-а" - идея потоков присутствовали в AIX & Solaris, да и в других, когда и Linux то ещё "не придумали"

Последний раз писал потоки около года назад в linux 2.4, используя именно pthread_*. Все-таки "как должно быть" и "как есть" - разные вещи. Мы говорим об одних и тех же вещах на разных языках. Выдержки из книги "Программирование под Linux. Профессиональный подход.":

"... Потоковые функции, соответствующие стандарту Posix, реализованы в Linux не так, как в большинстве других версий Unix. Суть в том, что в Linux потоки реализованы в виде процессов. Когда вызывается функция pthread_create(), операционная система на самом деле создает новый процесс, выполняющий поток. Но это не тот процесс, который создается функцией fork(). Он, в частности, делит общее адресное пространство и ресурсы с исходным процессом, а не получает их копии."

От себя добавлю, что при переключении потоков требуется изменять гораздо меньше структур и данных, чем при переключении процессов.

Ведь если подумать, зачем все эти исключения, взаимоблокировки, семафоры, если операционка сама взяла и распланировала как ей вздумается, и плевала она на мои семафоры. Русурсы в системе выделяются процессу, пользует их процесс, приоритет выставляется - процессу, а значит, я считаю, и объектом ядра является именно процесс.

Планирование в системах реального времени - это ваще отдельная песня. Вы правы, система реального времени не должна допускать взаимоблокировок НИКОГДА. И часто, при определенной настройке ("жесткая" система реального времени, "мягкая"), она может послать юзера с его планированием, чтобы только не допустить собственного краха.
Вероятно в QNX Posix реализован не так как в Linux.

2.4 glibc + 2.6 ядро, вернее в 2.4 glibc linuxthreads-реализация полностью исключена из библиотеки, до этого она поддерживалась наравне с NPTL.

Конечно разные: всякая вещь должна быть такой "как должно быть", а то "как есть" в отличие от "как должно быть" - это всё херня


Нет, мы говоим об одних вещах на разных языках: то, что цитируется из книжки (этой книжке в прошлую пятницу 10 лет исполнилось ) - относится как раз к "старой" реализации через clone, а то, что автор называет "не так" - правильнее называть "через задницу" ... о чём, впрочем, уже писано-переписано в публикациях, и от чего разработчики Linux уходят.


Да, но вы забываете, что в подавляющем большинстве случаев (практически всех кроме sched_yield и перехода в блокированное состояние типа sleep()) - переключение потоков (именно потоков, потому что переключение процессов - это фикция, процессы - это статическая сущность, оболочка) - происходит по системному тику, одновременно с которым происходит отработке службы времени и перепланирования, требующие времени T, которое на порядок или около того больше времени переключения контекстов t (будь это переключение хоть в рамках единого адресного пространства, хоть разных, т.е. между потоками), но кроме того, на перепланирование в любом случае происходит переключение в контекст ядра и кольцо защиты 0, так что практически одинаково куда потом возвращаться.... Это так, в общих чертах ... но я это проверял, в цифрах и не раз, и для различных (ну пусть "некоторых") ядер Linux и для QNX. Почему и говорю: мнение о "разительной" разнице переключений между потоками внутри одного процесса и в разных процессах - красивая народная легенда.


Здесь вообще полная "каша":
- ОС ведёт планирование только и именно в тех рамках, в которых ей позволяют ей текущие состояния примитивов синхронизации... а не "как ей вздумается"...
- ... а вы слышали, например, что захваченный мютекс всегда имеет "хозяина", и только он может разблокровать мютекс, и хозяин этот - всегда поток, и его pid_t просто прописывается в структуре мютекса, см. *.h определения...
- приоритеты, к примеру, также устанавливаются потокам: в рамках 1-го процесса может крутиться N потоков с N различными приоритетами ... более того, при взаимодействии потоко эти приоритеты могут плыть вверх-вниз (о наследовании приоритетов и граничных приоритетах - слышали?), так что ни вы ни процесс этого и не заметит, а если захотите - то и тогда не сможете вмешаться


Да нет там никаких песен - все дисциплины и процедуры планирования описаны POSIX и его расширениями, и ничего, кроме FIFO - раунд-робин - адаптивной - спорадической диспетчеризации (с тонкими отличиями в деталях реализации) никто и нигде не придумал.
А система, которая может "послать юзера" ? ... "пикантно, пикантно...."(с) - поручик Ржевский ... кто вам такие страсти рассказал? может это было в качестве анекдота?


Не вероятно, а точно :
- POSIX, и особенно его последние расширения (1003b и др.) - в QNX реалиованы гораздо строже и (почти) в полном соответствии.

Книжке 6 лет. Интересно, сколько лет ядру 2.4 со всеми его реинкарнациями?



Даже и не знаю чего сказать. Как будто процессорное время - это один единственный ресурс в системе. Может Вы знаете алгоритм планирования с заданным максиамльным временем отклика и
100%-но не допускающий взаимоблокировок?

Вообщем, спор надоел, а



не херня, а реалии жизни. Чем больше живешь тем больше убеждаешься. А поптом через 10 лет конторы вдруг заявит: вот, это как раз то что мы задумали еще ТОГДА..." (Как Microsoft делает с выходом каждой новой ОС).

Насколько я понял, в старой реализации linuxthread (которую я собственно юзаю) поток представлял из себя процесс с расшаренным адресным пространством. Плюс в каждом процессе запускался еще один поток для присмотра за остальными.
Таким образом, scheduling делало все-таки ядро (это мне нравится), но работать это может только в однопроцессорной системе (на это мне наплевать).
И еще для политики SCHED_OTHER приоритет может быть только 0.

Так?

Не стал открывать новую тему.

Возникла такая проблема:

я использую функции завершения потока, устанавливаемые макросом
pthread_cleanup_push
поток останавливается функцией
pthread_cancel

На PXA-255, ядро 2.4.19 компилятор gcc 3.3 все работает хорошо.

На Писюке с Ubuntu 7.04 компилятор gcc 4.1.2 (Ubuntu 4.1.2 - Qubuntu4) функции завершения потока, описанного в C - файле вызываются нормально. А вот функции завершения потока, описанного в CPP - файле не вызываются.

В чем может быть дело?