Тема, по которой не прекращаются споры сторонников различных подходов.
Но вот недавно SadKo предложил интересную идею, которой я не премину воспользоваться (Если, конечно, SadKo не будет сильно возражать и настаивать на своем исключительном авторском праве :)).
Идея в принципе не нова, и заключается в том, что переключениями задач занимается отдельная задача, что, собственно, упрощает процесс менеджмента. При этом я, скорее всего, не стану полностью переводить весь ядерный API в отдельные задачи, это не оптимальный и не самый удобный способ реализации, ИМХО. Более того, даже прерывание таймера не достойно того, чтобы выносить его в отдельную задачу. Тем более, что прерывание таймера вовсе не подразумевает переключения задачи, в том смысле что переключение может и не понадобиться.
Менеджер задач будет отдельной задачей, но не будет напрямую доступен приложениям, а будет вызываться самим ядром при необходимости такого переключения.
Конечно, это будет приводить к дополнительным расходам времени (одно дополнительное переключение задачи). Да ну и пусть. Зато удобно. В старой реализации мне приходилось постоянно ломать голову над тем, как проделать над задачей какие либо манипуляции, учитывая, что она еще не покинула процессор. И приходится мучиться.
PS: И еще подумал, что на многоядерной системе вероятно потребуется сделать несколько задач - переключателей (по одной на каждый процессор), или одну задачу но с блокировкой (этот вариант наверное попроще).
Построить Qt из исходников под Linux
2 недели назад
2 коммент.:
Прально мысль ловишь, что на каждый проц свой шедулер.
Это реально удобно. Но не надо забывать, что должен быть один главный шедулер, чтобы не получилось, что два проца одновременно запустили одну и ту же задачу. Либо присвоить нити свойство мьютекса. Чтобы она была заблокирована, когда активна.
З.Ы.
Пиши SadKo, а не Садко. Это две разные сущности :).
Ну разные шедулеры нужны для того, чтобы несколько процов не попыталось бы врубить одну задачу... или как вариант можно перед переключением на шедулер поставить блокировку. Просто при активном шедулере это будет Busy TSS, попытка переключиться на который вызовет исключение.
ИМХО с планированием это никак не связано. Всмысле там должны быть свои блокировки. На уровне очередей планировщика. Ну это я по логике своего ядра рассуждаю.
Просто очереди модифицируются не только при переключении задач, но и в других ситуациях.
В частности порождение новой нити не требует переключения задач.. Создали нить, запихнули ее в очередь, и работаем дальше. но модификация очереди требуется. Так что без блокировок там всеравно не обойтись.
PS: SadKo, fixed, извини :)
Отправить комментарий