POSIX pthread_* в Linux, когда появилось и как реализовано? Опции

[Johny]

В большинстве книг по Linux не упоминается Posix thread library - вызовы с префиксом pthread_ (типа pthread_create()). Однако я встречал упоминание, что в последних версиях Linux это реализовано. Начиная с какой версии? Это отдельная библиотека, или набор системных вызовов? В каком хедере описаны?
Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

[InvisibleFed]

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

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

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

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

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

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

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

[Olej]

Все-таки "как должно быть" и "как есть" - разные вещи.

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

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

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

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

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

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

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

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

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

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

Вероятно в QNX Posix реализован не так как в Linux.

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