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

[Johny]

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

[Harbour]

появилось в 1996 (имплементация Xavier Leroy), начиная с версии ядра 1.2.x и libc 4.x, инклюд <pthreads.h>. Это и набор системных вызовов (clone) и несколько юзер-спейс реализаций (linuxthreads/posixthreads/nptl/etc). Многопоточность имеет смысл для масштабирования, то бишь в многопроцессорных системах, к которым uclinux, насколько мне известно, не относится. При вопросах портирования можно выкрутиться юзер-спейс реализацией.

[v_shamaev]

Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

eCos - многопоточный, но не многопроцессный - threads - родные, есть posix-надстройка.
QNX - и процессы, и потоки, posix.
Что в более мелких - сейчас не помню.

[Johny]

появилось в 1996 (имплементация Xavier Leroy), начиная с версии ядра 1.2.x и libc 4.x, инклюд <pthreads.h>. Это и набор системных вызовов (clone) и несколько юзер-спейс реализаций (linuxthreads/posixthreads/nptl/etc). Многопоточность имеет смысл для масштабирования, то бишь в многопроцессорных системах, к которым uclinux, насколько мне известно, не относится. При вопросах портирования можно выкрутиться юзер-спейс реализацией.

Спасибо.
В ядре 2.6 ничего в этом плане не поменялось?
У меня сейчас 2.4.17 и glibc-2.3.1 для arm. Нашел реализацию pthread. Система однопроцессорная, в принципе, наверное без разницы, как реализовано, лишь бы работало нормально. Просто использование потоков мне кажется более удобным, чем создание кучи процессов, а затем разделяемой памяти для них - в рамках одного модуля приложения.

[Harbour]

В ядре 2.6 появился TLS и соответствующая поддержка в NPTL, последние версии libc (>= 2.4) уже старую схему не поддерживают. Новая схема работает быстрее, в некоторых тестах (pthread_exitfor ex.) до 1000 раз. Насчет целесообразности - это дело вкуса, если прога не планируется к переносу/запуску на MP системах, то смысла мутить на тредах не вижу. Кстати в свете новых веяний треды (openmp) как парадигма параллельного программирования уже устарели.

[KirillS]

появилось в 1996 (имплементация Xavier Leroy), начиная с версии ядра 1.2.x и libc 4.x, инклюд <pthreads.h>. Это и набор системных вызовов (clone) и несколько юзер-спейс реализаций (linuxthreads/posixthreads/nptl/etc). Многопоточность имеет смысл для масштабирования, то бишь в многопроцессорных системах, к которым uclinux, насколько мне известно, не относится. При вопросах портирования можно выкрутиться юзер-спейс реализацией.

Спасибо.
В ядре 2.6 ничего в этом плане не поменялось?
У меня сейчас 2.4.17 и glibc-2.3.1 для arm. Нашел реализацию pthread. Система однопроцессорная, в принципе, наверное без разницы, как реализовано, лишь бы работало нормально. Просто использование потоков мне кажется более удобным, чем создание кучи процессов, а затем разделяемой памяти для них - в рамках одного модуля приложения.

Я работаю с threads в uClinux 2.4.17 (MicroBlaze). Если создаётся небольшое число threads, то никаких проблем не возникает, но есть проблемы с числом threads ~> 10 (например таких)

[Playnet]

Кстати в свете новых веяний треды (openmp) как парадигма параллельного программирования уже устарели.

А что сейчас с веяниями? Как параллельные проги "правильнее" делать?

[AlexandrY]

Процессы и потоки выдумка Linux-а.
Там процессы настолько медленно переключаются, что пришлось придумать потоки.
В без MMU-ушных процах в RTOS процесы и потоки это одно и тоже и называются обычно задачами.

Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

eCos - многопоточный, но не многопроцессный - threads - родные, есть posix-надстройка.
QNX - и процессы, и потоки, posix.
Что в более мелких - сейчас не помню.

[v_shamaev]

Процессы и потоки выдумка Linux-а.
Там процессы настолько медленно переключаются, что пришлось придумать потоки.
В без MMU-ушных процах в RTOS процесы и потоки это одно и тоже и называются обычно задачами.

Процессы - это еще ранние UNIX-ы, а может и раньше, не знаю. А потоки - тоже в UNIX- и в OS/2 еще в первой. А тогда еще Линуксов не было.

[nazim]

В большинстве книг по Linux не упоминается Posix thread library - вызовы с префиксом pthread_

Книги скорее всего старые, в новых изданиях описываются вызовы POSIX threads (pthread_)
Пример: advancedlinuxprogramming.com

Однако я встречал упоминание, что в последних версиях Linux это реализовано. Начиная с какой версии?

Можно сказать во всех с ядром 2.6 и glibc >= 2.3.x, Насчет старых дистров с ядром 2.4 , не могу сказать точно, если есть, то бэкпортированно из 2.6 (у RHEL в особенности).

Это отдельная библиотека, или набор системных вызовов? В каком хедере описаны?
Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

POSIX Threads в линуксе "работают" в ядре, интерфейс пользователя в библиотеке libpthread, хэдэр <pthread.h>, линкуется соответственно через -lpthread. Всё описано в документации glibc.

Насчет uCLinux & co, Вам ничего сказать не могу, к сожалению никогда их не использовал

[sff]

Можно сказать во всех с ядром 2.6 и glibc >= 2.3.x, Насчет старых дистров с ядром 2.4 , не могу сказать точно, если есть, то бэкпортированно из 2.6 (у RHEL в особенности).

Это отдельная библиотека, или набор системных вызовов? В каком хедере описаны?
Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

POSIX Threads в линуксе "работают" в ядре, интерфейс пользователя в библиотеке libpthread, хэдэр <pthread.h>, линкуется соответственно через -lpthread. Всё описано в документации glibc.

Насчет uCLinux & co, Вам ничего сказать не могу, к сожалению никогда их не использовал

А точнее так: в ядре 2.4 были только процессы и все потоки с точки зрения ядра предствлялись процессами (только имели общую разделяемую память) с разными PID ами что можно было видеть соответствующими утилитами.
В 2.6 появилось native thread тоесть поток как сущность на уровне ядра. Соотвественно создание потока стало менее ресурсоемким.

Патч обеспечивающмй native thread в ядре существует, боюсь наврать, но он вроде не бэкпортированно из 2.6, а развивался сам по себе и в 2.6 просто его включили окончательно.

[Harbour]

Процессы и потоки выдумка Linux-а.
Там процессы настолько медленно переключаются, что пришлось придумать потоки.
В без MMU-ушных процах в RTOS процесы и потоки это одно и тоже и называются обычно задачами.

Как обстоят дела с многопоточностью в других uCLinux и других embedded ОСях?

eCos - многопоточный, но не многопроцессный - threads - родные, есть posix-надстройка.
QNX - и процессы, и потоки, posix.
Что в более мелких - сейчас не помню.

Процессы, как уже было замечено, это "выдумка" многозадачных систем, первыми из которых были Unix подобные где-то эдак в 60x годах В Linux'е же впервые были реализованы так называемые light треды, которые имели общее с родителем адресное пространство но раздельные политики счедулинга.

Кстати в свете новых веяний треды (openmp) как парадигма параллельного программирования уже устарели.

А что сейчас с веяниями? Как параллельные проги "правильнее" делать?

Для интересующихся - http://gcc.gnu.org/projects/gomp/

[makc]

А точнее так: в ядре 2.4 были только процессы и все потоки с точки зрения ядра предствлялись процессами (только имели общую разделяемую память) с разными PID ами что можно было видеть соответствующими утилитами.
В 2.6 появилось native thread тоесть поток как сущность на уровне ядра. Соотвественно создание потока стало менее ресурсоемким.

Патч обеспечивающмй native thread в ядре существует, боюсь наврать, но он вроде не бэкпортированно из 2.6, а развивался сам по себе и в 2.6 просто его включили окончательно.

Не совсем так. Цитирую Linux Kernel Development Second Edition By Robert Love:

Threads are a popular modern programming abstraction. They provide multiple threads of execution within the same program in a shared memory address space. They can also share open files and other resources. Threads allow for concurrent programming and, on multiple processor systems, true parallelism.

Linux has a unique implementation of threads. To the Linux kernel, there is no concept of a thread. Linux implements all threads as standard processes. The Linux kernel does not provide any special scheduling semantics or data structures to represent threads. Instead, a thread is merely a process that shares certain resources with other processes. Each thread has a unique task_struct and appears to the kernel as a normal process (which just happens to share resources, such as an address space, with other processes).

This approach to threads contrasts greatly with operating systems such as Microsoft Windows or Sun Solaris, which have explicit kernel support for threads (and sometimes call threads lightweight processes). The name "lightweight process" sums up the difference in philosophies between Linux and other systems. To these other operating systems, threads are an abstraction to provide a lighter, quicker execution unit than the heavy process. To Linux, threads are simply a manner of sharing resources between processes (which are already quite lightweight)[11]. For example, assume you have a process that consists of four threads. On systems with explicit thread support, there might exist one process descriptor that in turn points to the four different threads. The process descriptor describes the shared resources, such as an address space or open files. The threads then describe the resources they alone possess. Conversely, in Linux, there are simply four processes and thus four normal task_struct structures. The four processes are set up to share certain resources.

[11] As an example, benchmark process creation time in Linux versus process (or even thread!) creation time in these other operating systems. The results are quite nice.

Threads are created like normal tasks, with the exception that the clone() system call is passed flags corresponding to specific resources to be shared:

clone(CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND, 0);

The previous code results in behavior identical to a normal fork(), except that the address space, filesystem resources, file descriptors, and signal handlers are shared. In other words, the new task and its parent are what are popularly called threads.

В книге речь идет о ядре 2.6

[sff]

2 makc Извеняюсь, что наврал..
хоть и появились ktread_* в <linux/kthread.h>, но, действительно, kthead_create возвращает task_struct..

[makc]

2 makc Извеняюсь, что наврал..
хоть и появились ktread_* в <linux/kthread.h>, но, действительно, kthead_create возвращает task_struct..

Думаю, что всем будет полезна эта книга в электронном варианте.
Забрать ее можно здесь - http://nukeuploads.com/download/1169196826...LKD2Ed.rar.html

[v_shamaev]

Думаю, что всем будет полезна эта книга в электронном варианте.
Забрать ее можно здесь - http://nukeuploads.com/download/1169196826...LKD2Ed.rar.html

Пустая страница открывается по ссылке. Как хоть называется эта книга?

[makc]

Думаю, что всем будет полезна эта книга в электронном варианте.
Забрать ее можно здесь - http://nukeuploads.com/download/1169196826...LKD2Ed.rar.html

Пустая страница открывается по ссылке. Как хоть называется эта книга?

Да, действительно. Это тем более странно, что после заливки я проверил - файл был доступен.
Книга называется Linux Kernel Development Second Edition By Robert Lovе
Залил ее еще раз, на другой файлообменник - http://www.rapidshare.ru/148214

[v_shamaev]

Думаю, что всем будет полезна эта книга в электронном варианте.
Забрать ее можно здесь - http://nukeuploads.com/download/1169196826...LKD2Ed.rar.html

Пустая страница открывается по ссылке. Как хоть называется эта книга?

Да, действительно. Это тем более странно, что после заливки я проверил - файл был доступен.
Книга называется Linux Kernel Development Second Edition By Robert Lovе
Залил ее еще раз, на другой файлообменник - http://www.rapidshare.ru/148214

Хорошая книга, хорошо написана. Есть в продаже русский перевод - "Роберт Лав. Разработка ядра Linux. Второе издание"

ББК 32.973.26-018.2.75

Не со всеми утверждениями (или, точнее, акцентами) я согласен, как раз по поводу потоков.

[makc]

Хорошая книга, хорошо написана. Есть в продаже русский перевод - "Роберт Лав. Разработка ядра Linux. Второе издание"

Да, есть такая книга. Я себе прикупил. В принципе, читать можно. Есть, правда, проблемы перевода, но куда же без них.

Не со всеми утверждениями (или, точнее, акцентами) я согласен, как раз по поводу потоков.

С чем именно Вы не согласны?

[Playnet]

Думаю, что всем будет полезна эта книга в электронном варианте.
Забрать ее можно здесь - http://nukeuploads.com/download/1169196826...LKD2Ed.rar.html

Пустая страница открывается по ссылке. Как хоть называется эта книга?

у меня скачалось. Могу на ifolder залить
хттп://ifolder.ru/910949

Сообщение отредактировал Playnet - Jan 19 2007, 20:02

[Olej]

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

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

Это и набор системных вызовов (clone) и несколько юзер-спейс реализаций (linuxthreads/posixthreads/nptl/etc).

В этом clone и состоит беда Linux реализации.

В ядре 2.6 ничего в этом плане не поменялось?
У меня сейчас 2.4.17 и glibc-2.3.1 для arm. Нашел реализацию pthread. Система однопроцессорная, в принципе, наверное без разницы, как реализовано, лишь бы работало нормально. Просто использование потоков мне кажется более удобным, чем создание кучи процессов, а затем разделяемой памяти для них - в рамках одного модуля приложения.

Поменялось . Принципиально. Начиная с 2.6 модель потоков Linux стала гораздо ближе (в своём поведении, а не сколько в виде системных вызовов) к POSIX. А до этого был совершенно уродливый конгломерат, обязанный именно clone.

Посмотрите здесь:
http://www.books.ru/shop/books/357604
или хотя бы здесь:
http://qnxclub.net/files/articles/pthread/pthread.pdf

Процессы и потоки выдумка Linux-а.

Ага, ща-а-а-з... а до Linux была, оказывается, голая пустыня ...
Потоки присутствуют во всех UNIX-like системах начиная с 80-Х ... ну, второй половины 80-х. И стандартизованы расширением POSIX1003.b.

[Harbour]

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

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

Если программу предназначенную для работы на 1 cpu, программист пишет с использованием тредов, то ему еще долго шагать по пути к мастерству.

Это и набор системных вызовов (clone) и несколько юзер-спейс реализаций (linuxthreads/posixthreads/nptl/etc).

В этом clone и состоит беда Linux реализации.

Уже много лет пользую потоки в linux, начиная с ядра 2.0, никаких бед что-то не замечено.

[InvisibleFed]

Имеется книженция "Unix. Взаимодействие процессов" Автор: Уильям Стивенс. Тамдовольно толково и про процессы и про потоки (правда немного теоретизировано). Куда слить?

[makc]

Имеется книженция "Unix. Взаимодействие процессов" Автор: Уильям Стивенс. Тамдовольно толково и про процессы и про потоки (правда немного теоретизировано). Куда слить?

http://nukeuploads.com/

[beer_warrior]

Если программу предназначенную для работы на 1 cpu, программист пишет с использованием тредов, то ему еще долго шагать по пути к мастерству.

Стоп-стоп.
Вы хотите сказать, что трэды это только для мультипроцессорных систем?

[makc]

Если программу предназначенную для работы на 1 cpu, программист пишет с использованием тредов, то ему еще долго шагать по пути к мастерству.

Стоп-стоп.
Вы хотите сказать, что трэды это только для мультипроцессорных систем?

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

[InvisibleFed]

Книжку на днях постараюсь залить. Сообщу.

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

Спорное утверждение. Пока один поток ожидает завершение операции ввода-вывода, второй может использовать процессор. Конечно, потоки это лиш уровень абстракции, но организовать подобное БЕЗ потоков - еще тот гемор и, видимо, не всегда возможно. Общую производительность таким образом, конечно, не повысишь (процессор все-таки один), но так называемую "ощущаемую" - вполне.

[Harbour]

Если программу предназначенную для работы на 1 cpu, программист пишет с использованием тредов, то ему еще долго шагать по пути к мастерству.

Стоп-стоп.
Вы хотите сказать, что трэды это только для мультипроцессорных систем?

Нет конечно Имелось ввиду приложение по теме, т.е. в uclinux, где SMP нет в природе а лишний гемор и потеря времени при написании тредовой app обеспечен. Работать такое приложение будет тоже медленнее - кроме тормозов при переключение контекста имеем дополнительные потери на счедулинг каждой треды и на организацию блокировок данных внтури одной и той же программы.
И последнее - неизвестно насколько эффективна реализована поддержка тредов в изначально ембеддерской однопроцессорной системе, где их активное использование, собственно, не предусмотрено. С нормальным linux'ом на обычном современном железе разница заметна только для маньяков скорости

[InvisibleFed]

Работать такое приложение будет тоже медленнее - кроме тормозов при переключение контекста имеем дополнительные потери на счедулинг каждой треды и на организацию блокировок данных внтури одной и той же программы.
И последнее - неизвестно насколько эффективна реализована поддержка тредов в изначально ембеддерской однопроцессорной системе, где их активное использование, собственно, не предусмотрено. С нормальным linux'ом на обычном современном железе разница заметна только для маньяков скорости.

Там где можно использовать треды, а не процессы - нужно использовать треды. Переключение тредов происходит гораздо быстрее. Что касается шедулинга, то на системном уровне его нет как такового (тред не является объектом ядра linux, насколько мне известно), управление на пользовательском уровне связано скорее с опытом. А по производительности - я уже свое мнение высказал.

Сообщение отредактировал InvisibleFed - Jan 21 2007, 11:39

[makc]

Там где можно использовать треды, а не процессы - нужно использовать треды. Переключение тредов происходит гораздо быстрее. Что касается шедулинга, то на системном уровне его нет как такового (тред не является объектом ядра linux, насколько мне известно), управление на пользовательском уровне связано скорее с опытом. А по производительности - я уже свое мнение высказал.

Вы прокакое ядро говорите? Если про 2.6, то чуть раньше мы тут уже выяснили, что в нем треды реализуются через процессы с разделяемым адресным пространством (и другими данными). Т.е. являются объектами шедулинга и, соотвественно, объектами ядра.

[InvisibleFed]

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

[makc]

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

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

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

[Olej]

Переключение тредов происходит гораздо быстрее. Что касается шедулинга, то на системном уровне его нет как такового (тред не является объектом ядра linux, насколько мне известно), управление на пользовательском уровне связано скорее с опытом. А по производительности - я уже свое мнение высказал.

Вы прокакое ядро говорите? Если про 2.6, то чуть раньше мы тут уже выяснили, что в нем треды реализуются через процессы с разделяемым адресным пространством (и другими данными). Т.е. являются объектами шедулинга и, соотвественно, объектами ядра.

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

Робяты ... 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 это смазывается его монолитным макроядром .

[path_finder]

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

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

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

[Olej]

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

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

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

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

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

[Harbour]

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

[InvisibleFed]

Из POSIX определения уже понятно, что именно только и исключительно потоки и могут быть объектом решедулирования. И поэтому потоки просто не могут не быть объектами ядра ... Иллюзию путаницы здесь создаёт то, что всякий процесс, хотите вы того или нет , имеет как минимум 1 поток - главный, main() - вот он у вас и решедулируется под видом процесса. А процесс - это просто мёртвая статическая оболочка над потоком, служащая менеджеру процессов для занесения туда статистической и учётной информации, типа "занимаемое процессорное время"...

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

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

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

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

[Olej]

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

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

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

[Olej]

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

Процессы и потоки выдумка Linux-а.
Там процессы настолько медленно переключаются, что пришлось придумать потоки.
В без MMU-ушных процах в RTOS процесы и потоки это одно и тоже и называются обычно задачами.

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

[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.

[Harbour]

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

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

[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 реалиованы гораздо строже и (почти) в полном соответствии.

[InvisibleFed]

этой книжке в прошлую пятницу 10 лет исполнилось

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

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

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

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

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

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

[Johny]

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

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

Так?

[Johny]

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

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

я использую функции завершения потока, устанавливаемые макросом
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 - файле не вызываются.

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

[Olej]

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

... я надеюсь он закрывается макросом pthread_cleanup_pop ?

поток останавливается функцией
pthread_cancel

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

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

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

В ошибках в коде ... например неправильной передаче pthread_cleanup_push адреса процедуры завершения, а ещё скорее - для неё параметров... кстати, функция потока в этом случае не должна завершаться pthread_cancel(), а должна pthread_cleanup_pop( 1 )...
Механизм pthread_cleanup_... , стека процедур завершения - нормально работает не только в GCC с соответствующим libstd 4.х, 3.х - но и 2.95.х ...

Ищите ошибку
Точнее можно только по коду сказать.

[Johny]

... я надеюсь он закрывается макросом pthread_cleanup_pop ?
В ошибках в коде ... например неправильной передаче pthread_cleanup_push адреса процедуры завершения, а ещё скорее - для неё параметров... кстати, функция потока в этом случае не должна завершаться pthread_cancel(), а должна pthread_cleanup_pop( 1 )...
Механизм pthread_cleanup_... , стека процедур завершения - нормально работает не только в GCC с соответствующим libstd 4.х, 3.х - но и 2.95.х ...

Ищите ошибку
Точнее можно только по коду сказать.

pthread_cleanup_pop конечно же стоит - без него код не компилируется.

Код функции потока очень простой, в чем может быть ошибка - непонятно (чтобы нормально работало на писюке ввел флаг MesureRunning, для остановки потока вместо вызова pthread_cancel, сбрасываю флаг. Если не объявлять LINUX_PC, на писюке функция DestroyMesurer все равне не вызывается, и как следствие объект класса CImpMesurer не дестроится ).


#ifdef LINUX_PC
static int MesureRunning = 0;
extern "C" void* MesureProc (void* param);
#else
extern "C" static void* MesureProc (void* param);
extern "C" static void DestroyMesurer(void* Mesurer);
#endif

/*...Код других функций...*/

extern "C" void* MesureProc(void* param)
{
bool res;
int ret;
double RP, RM, RZ;
CImpMesurer* Mesurer;
MesureThreadPar *ThrParam = (MesureThreadPar*) param;
void ( *ReceiveImpedance)(void* ID, double RP, double RM, double RZ, int res);

void* ID = ThrParam->ID;
ReceiveImpedance = ThrParam->ReceiveImpedance;

free(ThrParam);

Mesurer = new CImpMesurer();

#ifdef LINUX_PC
while(MesureRunning==1)
#else
pthread_cleanup_push(&DestroyMesurer,(void*)Mesurer); /* add termination handler*/

while(1)
#endif
{
pthread_testcancel(); /* Tect cancel thread */
res=Mesurer->Mesure(&RP, &RM, &RZ); /* impedance mesure */
ret=res?0:1;
ReceiveImpedance(ID, RP, RM, RZ, ret); /*call call-back function*/
}
#ifndef LINUX_PC
pthread_cleanup_pop (1);
#else
delete Mesurer;
#endif
return NULL;
}

#ifndef LINUX_PC
extern "C" void DestroyMesurer(void* Mesurer)
{
delete (CImpMesurer*) Mesurer;
#ifdef DEBUG_
errout = fopen("/tmp/AudioAPIErr", "a");
fprintf(errout, "DestroyMesurer()\n");
fclose(errout);
#endif
}
#endif //LINUX_PC

[Olej]

pthread_cleanup_pop конечно же стоит - без него код не компилируется.

Это уже хорошо
"больной перед смертью потел? о! - это очень, очень хорошо"(с)

Код функции потока очень простой, в чем может быть ошибка - непонятно (чтобы нормально работало на писюке ввел флаг MesureRunning, для остановки потока вместо вызова pthread_cancel, сбрасываю флаг. Если не объявлять LINUX_PC, на писюке функция DestroyMesurer все равне не вызывается, и как следствие объект класса CImpMesurer не дестроится ).

Ваш код слишком перегружен деталями ... чтобы в нём детально разбираться
Я привык для непонятных мне вопросов вычленять специальный пример без всяких частностей и #if ... - сильно помогает...
Но "на вскидку" в вашем примере ничего крамольного не видно... должон работать
Гляньте:
http://qnxclub.net/modules.php?name=Forums...92&start=30
- там типично ваш пример, только в куда более изощрённых условиях... с прогонами и работающий...
Прогонялся он, правда, в QNX а не LINUX, в QNX гораздо более жёстко API следует семантике POSIX и ведёт себя соответствующе...
Прогоните такой (усечённый) пример в LINUX - будет сразу работать, значит у вас в чём-то недосмотр, не будет сразу работать - значит нужно что-то с опциями компиляции подыграть ... такое в LINUX бывает

P.S. кстати, я совершенно не понял: "Если не объявлять LINUX_PC, на писюке ..."©
- кто такой писюк? а на чём это ещё (в каких условиях? в какой ОС? или что...) должно выполняться?

[Johny]

P.S. кстати, я совершенно не понял: "Если не объявлять LINUX_PC, на писюке ..."©
- кто такой писюк? а на чём это ещё (в каких условиях? в какой ОС? или что...) должно выполняться?

Писюк - это слэнг такой, означает х86 компьютер

-Сделал условную компиляцию для х86 машины: если объявлен LINUX_PC, pthread_cleanup_push не используется