Цитата
В нормальной реализации потоков (я не знаю, до какой степени уже "нормальная" реализация в 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.