OSDev

Я считаю, что надо непосредственно в ядре поддерживать потоки. Имхо потоки программным способом - это костыль :).
Что касается системных вызовов, то набор их по работе с потоками надо сделать минимальным (создание, уничтожение, останов). Остальное всё вынести в прикладную библиотеку.
При этом ещё планировщику надо будет выбирать, какому из потоков давать возможность обрабатывать приходящий извне сигнал. Обычно это поток, который был создан первым :).

А я думаю есть два взгляда на единицы выполнения...
Вернее три взгляда, но третий - это взгляд майкрософт, о нем позже...

Первый взгляд - это процессы...
Системы организовывались на основе процессов, и даже ядерные нити в таких системах - суть костыли. В линуксе каждая нить - это как-бы отдельный процесс. но они там как бы шарятся между собой, и получается общее адресное пространство. там какие-то объединяющие сущности применяются...
То есть получается Процесс - это все, а нить - это условность, данная нам в ощущениях через АПИ. :)

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

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

Последним путем движется MDF.

Я еще слышал про некоторые waves, (вроде бы в винде существуют), которые тоже вроде бы нити, но чисто программные.
С точки зрения ядра обсуждать это бессмысленно.

А что касается pthreads - то это обычно расшифровывается как POSIX Threads, то есть некий стандарт API...
legos, если ты говоришь про нити вообще то употребление этого термина некорректно.

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

Phantom-84, Слишком много возможностей - это плохо ИМХО... :) Нужна одна система планирования - единственно правильная! :)

Хотя алгоритмы планирования можно менять. :)

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

Не все виды многопоточности можно реализовать исключительно на прикладном уровне, например, осуществить файловый ввод-вывод и при этом постоянно контролировать отклик наврядли получится без системной поддержки многопоточности (хотя здесь все зависит от уровня сложности реализации обрабортки сигналов). Надеюсь, основной вопрос топика снят?

Я почти уверен, что ты с большим энтузиазмом станешь использовать стандартную, нежели стороннюю библиотеку при условии, что они предоставляют одни и те же возможности. Я, например, точно стану : - ) Смысл сказанного мной ранее заключается именно в этом.

[ontop]

[/ontop] :mrgreen:

В многопоточность не надо вникать... ее надо понимать! :)

А в остальном - чем прозрачнее и проще это реализовано - тем лучше.