Linux 1.2 пока был достаточно оптимизирован как система разделения времени, где успешно выполняются множество прикладных программ, запущенных несколькими пользователями, т.е. редакторы, компиляторы, отладчики, X-сервер, сетевые демоны, и т.д.
Однако имеются много приложений, для которых Linux в настоящее время
не годен к употреблению и для которорых даже, готовый умереть за Linux,
твердолобый энтузиаст должен хранить автономную версию DOSа на диске.
Для 
этих программ факт в том, что Linux не может гарантировать
время ответа для запросов этих приложений
- главная проблема. Программное обеспечение для
управления, например EPROM программатором, руки робота, или астрономической CCD
камерой не осуществим под классическим Unix, если там нет выделенного
контроллера реального времени, встроенном в управляемом устройстве.
Много коммерчески доступных аппаратных средств ЭВМ было разработано с учетом "способности" работы в реальном масштабе времени в памяти под ДОС и не имеют никакого собственного микроконтроллера для критичных по времени операций.
Живой, достаточно общий пример: я плачевно потратил длительное личное время на попытки осуществить интерфейс к телевизионной плате декодера для Linux ( который эмулирует карту чипа и позволяет вам смотреть телепрограммы бесплатно :- ). В этом приложении вы должны ждать приход байта на последовательном порте, затем вы должны ждать от 0.7 до 2 ms (ни вкоем случае не меньше и не больше, иначе TV-декодер дает тайм-оут и стоп!) перед возвращением байта ответа. Фактически невозможно осуществить это из процесса пользователя для этой задачи под Linux 1.2, в то время как это тривиально сделать под ДОСом.
Я ожидаю дня, когда Linux обеспечит достаточный объем поддержки в реальном масштабе времени для этого приложения, так что-бы я мог, наконец, снести МС-ДОС с моего жесткого диска.
Для этих и подобных запросов в реальном масштабе времени, POSIX.1b определяет три различных планировщика, каждый со статическими приоритетами:
| SCHED\_FIFO |
Приоритетный, основанный на приоритетах планировщик. Каждый
процесс управляемый под этим приоритетом планирования
использует CPU до тех пор пока, (a) это не блокирует и
(b) его не прерывает другой, имеющий более высокий приоритет;
другие процессы ждут очереди. Существует FIFO очередь
для каждого уровня приоритетов и каждого процесса которая
добирается до его запуска и снова вставляет в очередь позади
всех других процессов. Это - наиболее популярный планировщик, используемый в типичных операционных системах в реальном масштабе времени. Функция sched\_yield() позволяет процессу идти к концу FIFO очереди без блокирования. |
| SCHED\_RR |
Приоритетный, приоритет основанный вокруг robin планирования
стратегии с квантами. Это очень схоже с SCHED\_FIFO, однако
каждый процесс имеет фиксированный квант времени и процесс становится
выгружаемым и вставляется в конце FIFO для соответствующего
уровня приоритетов, если он выполняется за более
длинный промежуток, чем квант времени а другие процессы того
же самого уровня приоритетов ждут в очереди. Для процессов более низких приоритетов с SCHED\_FIFO возможно, когда они никогда не получат CPU, если только процесс более высокого уровня оказывается в очереди. Если более приоритетный процесс становится готовым к запуску, то получает CPU немедленно. |
| SCHED\_OTHER | Это планировщик одинаково определенный для всех процесоов. Под Linux это - классический планировщик разделения времени с "хорошими" свойствами, и пр. Под Linux, все процессы SCHED\_OTHER разделяют общий статический приоритет со значением 0. |
По соображениям безопасности, только суперпользовательские процессы должны под Linux позволять получить любой статический приоритет выше чем для SCHED_OTHER, потому, что если механизмами планирования в реальном масштабе времени злоупотребить, может быть блокирована вся система.
Если кто-то разрабатывает приложение в реальном масштабе времени, очень хорошая идея иметь шелл с более высоким статическим приоритетом, особенно если надо убивать проверяемое приложение в случае если что-нибудь не работает. Вы должны помнить, если вы используете X11, не только шелл, но также X server, менеджер окна и xterm будет требовать более высокий статический приоритет, чтобы остановить процессы блокирующие остальную систему. Поэтому проверяющему программное обеспечение в реальном масштабе времени будет лучше выполнять его с консоли.
С этими POSIX.1b функциональными возможностями, возможно управлять программным обеспечением в реальном масштабе времени под Linux давая суперпользователю разрешение и назначение SCHED_FIFO стратегии и более высокий статический приоритет, чем всем другим классическим SCHED_OTHER Linux процессам. Кроме того, типичное приложение в реальном масштабе времени захватывает свои страницы с помощью mlockall() в память чтобы избегать своппинга. Это гарантирует, что данное приложение в реальном масштабе времени сможет реагировать наиболее быстро на любые прерывания и, что на время ответа не повлияет сложный стандартный Linux- механизм разделения времени приоритета или мониторинга.
Однако, пожалуйста прочтите также далее главу про времена ожидания прерывания!
Новые функции - здесь: sched_setparam(), sched_getparam(), sched_setscheduler(), sched_getscheduler(), sched_yield(), sched_get_priority_max(), sched_get_priority_min(), sched_rr_get_interval().
Состояние выполнения: sched_*() системные запросы теперь доступны начиная c Linux 1.3.55 (Markus Kuhn mskuhn@cip.informatik.uni-erlangen.de). Хотя большое количество тестов, оценка выполнения и оптимизация с планировщиком в реальном масштабе времени необходимы (особенно в отношении "быстрых" обработчиков прерываний, см. ниже ), вы можете уже использовать sched_*() запросы чтобы получить процессор в исключительное пользование. Имеются также libc и доступное описание. Еще раньше эту работу проделал David F. Carlson (carlson@dot4.cом). В его POSIX.4_scheduler патч исправляет Linux 1.2 (все еще доступный на sunsite).