Аналогичный подход к организации подсистемы планирования был предложен раньше Кон Коливас (Con Kolivas) [8,9]. Коливас первым предложил идею модульной организации планировщика, и выдвинул на обсуждение свою первую реализацию. Тем не менее, автор ядра Linux - Линус Торвальдс (Linus Torvalds) отклонил предложенную реализацию. Принципиальное отличие варианта Коливаса от Молнара заключается в возможности выбора нужного алгоритма планировщика в момент функционирования ОС. Это разногласие послужило поводом к бурным спорам в обществе ОС Linux. По мнению Молнара и Торвальдса планировщик задач является очень низкоуровневой частью ОС, должен четко и предсказуемо функционировать, и быть пригодным для использования во многих случаях, и пользователь должен довольствоваться стандартным планировщиком. Коливас же настаивает, что пользователь должен иметь право выбора нужного ему планировщика, и предлагает более гибкую архитектуру для построения необходимой среды выполнения.
В качестве замены стандартного алгоритма планировщика ядра 2.6.x, Коливас предложил свою реализацию алгоритма Staircase Deadline(SD) или же Rotating Staircase Deadline (RSDL).
На основе анализа работ Коливаса кратко опишем свойства этого алгоритма:
в сущности, алгоритм не позволяет «голодать» нитям, вне зависимости от нагрузки ЦПУ;
нет суждения об интерактивности нитей;
нет бонусного механизма;
фактически полное справедливое распределение ЦПУ, основано на статическом приоритете (nice) задач;
маленькое время задержки (latency) с эффективным deadline механизмом;
отличная интерактивность задач в допустимых пределах ограничений, накладываемых предыдущими пунктами;
время работы планировщика оценивается в O(1);
также как и в текущем планировщике ядра 2.6.х используется двойной битовый массив (что в некоторой мере вносит недостатки);
использование статических приоритетов (nice) для распределения времени ЦПУ очень эффективно.
На наш взгляд, подход Коливаса представляется более практичным, хотя он и был отклонен. Гораздо удобней передать ядру параметр, который бы указывал, какой планировщик использовать. В данном походе отпала бы необходимость перекомпиляции ядра для изменения алгоритма планирования. Несомненным плюсом также оказалась бы возможность использовать один планировщик в окружении другого планировщика по иерархической структуре. Такая схема позволяет более гибко создавать необходимую инфраструктуру для выполнения задач.
Но, тем не менее, на наш взгляд, разработка планировщика на текущем этапе остановиться не может. Это связано с быстрым развитием микропроцессорной техники и возникновением новых потребностей у пользовательских приложений. Особенно актуальной становится улучшенная поддержка задач реального времени. Это дает повод для разработки алгоритма планирования, которой можно будет использовать в случаях возникновения необходимости выполнять многоцелевые задачи, требующие обслуживания в реальном времени.