418ImATeapot писал(а):
Приоритетов ОЧЕНЬ много. Но они интересуют только планировщик, свитчер использует только два приоритета - RealTime and Normal. Суть в том, что планировщик выбирает наиболее приоритетные Normal потоки и отправляет их свитчеру, чтобы свитчеру самому не возиться с приоритетами.
Так и есть. Свитчер работает только с текущей кольцевой очередью. Переключением кольцевых очередей занимается планировщик.
Цитата:
Очередь свитчера фиксированной длины, для скорости. Делать ее динамической - по-моему слишком затратно.
Слишком затратно делать ее статической. Свитчер делает только одну короткую операцию - при истечении кванта времени текущего потока переключается на следующий поток в этой очереди.
Цитата:
Возможно, я неправильно понимаю термин RealTime. У меня это - поток который занимает точно 1/(длинна Раунд-Робина) апптайма (в данном случае 1/64).
Тут есть несколько различные трактовки. Но в целом realtime-поток - это поток, который выполняется до тех пор, пока либо сам не отдаст управление (потоку с таким же приоритетом), либо пока не будет прерван еще более приоритетным realtime-потоком. У меня есть единственный в своем роде system realtime-поток (максимальный приоритет), который за счет своей уникальности автоматически вытесняет все остальные потоки. Обычные realtime-потоки сейчас работают по принципу "application realtime" - это когда они также являются вытесняемыми по таймеру, только их кванты соответствуют реальным временным промежуткам, определяемым разработчиками ПО, а не генерируются ядром ОС, исходя из своих собственных интересов, уровня производительности аппаратуры и т.п. При таких условиях свитчер может даже не делать различий между normal- и realtime-потоками, т.к. по таймеру переключаются и одни, и другие, а system realtime- не переключается за счет того, что он единственный.
Цитата:
Я имел в виду другое. Ядро, которое запускается в потоке, из которого было вызвано - это только распределитель ресурсов и IPC. Все остальное - в паралельных поотоках (возможно, с приостановкой основного потока).
Т.е. ты предлагаешь на каждый "чих" приложения (обращение к ядру) запускать отдельный realtime-поток? Слишком накладно. Пусть уж лучше конкретный системный вызов определяется с тем, нужно ли ему запускать новый поток, обращаться к какому-либо служебному потоку ядра или все можно сделать "по-быстрому" в контексте текущего потока.