Отрицательные стороны выполнения процессов с приоритетом в реальном времени?

Самая непосредственная оборотная сторона выполнения процесса в реальном времени - то, что процесс может легко исчерпать ресурсы любой процесс в системе. Результат Вашей точки зрения будет состоять в том, что компьютер абсолютно безразличен на клавиатуру, мышь и вероятно сеть, столько, сколько процесс в реальном времени использует ЦП. Это может произойти, если что-то идет не так, как надо, и процесс входит в бесконечный цикл, или даже временно, если процесс запускает продолжительное вычисление, не ожидая входа периодически. (Так, например, не выполняйте SETI@home с приоритетом в реальном времени.)

Одинокий однопоточный процесс на многоядерном ЦП, менее вероятно, вызовет эту проблему, так как существуют другие ядра, которые может использовать процесс более низкого приоритета. Но если тот процесс создаст какие-либо дочерние процессы, то они наследуют тот же приоритет в реальном времени, таким образом, вещи смогут выйти из-под контроля, если Вы не осторожны.

sched_setscheduler(2) страница справочника имеет хороший совет:

Так как не блокирующийся бесконечный цикл в процессе, запланированном под SCHED_FIFO или SCHED_RR, заблокирует все процессы с более низким приоритетом навсегда, разработчик программного обеспечения должен всегда сохранять доступным на консоли оболочка запланированный под более высоким статическим приоритетом, чем протестированное приложение. Это позволит чрезвычайное уничтожение протестированных приложений реального времени, которые не блокируются или завершаются как ожидалось. См. также описание предела ресурса RLIMIT_RTTIME в getrlimit (2).

Это должно быть оболочкой на консоли - не под Xterm, если Вы не хотите отдать весь X приоритетов в реальном времени также.