要让Linux进程以实时FIFO调度运行，需使用chrt命令或sched_setscheduler系统调用设置调度策略与优先级，如sudo chrt -f 99 ./app或在C程序中配置SCHED_FIFO及优先级参数，同时确保进程具有CAP_SYS_NICE能力或root权限，并通过limits.conf配置rtprio和memlock限制以保障实时性，避免优先级反转需使用支持优先级继承的互斥锁。
在Linux系统中，要让一个进程以实时（real-time）模式运行并采用FIFO（First-In, First-Out）调度策略，核心在于利用特定的系统调用或工具来改变进程的调度属性，赋予它更高的优先级和非抢占式（在同优先级下）的执行保证。这通常意味着该进程将尽可能快地获得CPU时间，并且一旦运行，除非它主动放弃CPU或被更高优先级的实时进程抢占，否则会一直运行下去。
要实现Linux中的实时进程并应用FIFO调度策略，我们可以通过以下几种方式来操作：
解决方案
最直接的方式是使用
chrt命令或在程序中使用
sched_setscheduler系统调用。
-
使用
chrt
命令（命令行工具）chrt
命令允许你查询或修改一个运行中进程的实时调度属性，或者以指定的调度策略和优先级启动一个新程序。-
设置一个新进程为FIFO实时调度：
sudo chrt -f 99 ./my_realtime_app
这里，
-f
指定了FIFO调度策略（SCHED_FIFO
），99
是优先级（范围通常是1-99，其中99最高）。./my_realtime_app
是你要运行的实时应用程序。 -
修改一个已运行进程的调度策略和优先级： 首先，你需要知道进程的PID。
sudo chrt -f -p 99
这会将指定PID的进程设置为FIFO策略，优先级为99。
-
查看进程的调度信息：
chrt -p
或者通过
ps -eo pid,cls,rtprio,comm
命令来查看。cls
会显示调度类别（如TS
代表SCHED_OTHER
，FF
代表SCHED_FIFO
）。
-
-
在C/C++程序中使用
sched_setscheduler
系统调用对于需要更精细控制的应用，直接在代码中设置是更常见的做法。
#include
#include #include #include #include int main() { struct sched_param param; int max_prio, min_prio; // 获取SCHED_FIFO的最大和最小优先级 max_prio = sched_get_priority_max(SCHED_FIFO); min_prio = sched_get_priority_min(SCHED_FIFO); if (max_prio == -1 || min_prio == -1) { perror("Error getting priority range"); return 1; } printf("SCHED_FIFO priority range: %d to %d\n", min_prio, max_prio); // 设置优先级，通常我们会选择一个较高的值，但要小心 param.sched_priority = max_prio - 10; // 例如，设置为最大优先级减10 // 尝试将当前进程设置为SCHED_FIFO调度策略 if (sched_setscheduler(0, SCHED_FIFO, ¶m) == -1) { perror("Error setting scheduler policy"); // 权限不足通常是这里失败的原因，需要root权限或CAP_SYS_NICE能力 if (errno == EPERM) { fprintf(stderr, "Permission denied. Try running with sudo or check capabilities.\n"); } return 1; } printf("Process set to SCHED_FIFO with priority %d.\n", param.sched_priority); // 模拟实时任务 long long counter = 0; while (1) { counter++; // 这里可以放置你的实时任务逻辑 // 避免无限循环不放弃CPU，可能导致系统其他部分无响应 // 实际应用中会包含 sched_yield() 或等待事件 if (counter % 100000000 == 0) { // 每隔一段时间打印一次，模拟工作 printf("Real-time task running... Counter: %lld\n", counter); // sched_yield(); // 适当放弃CPU，让同等或更低优先级的进程有机会运行 } } return 0; } 编译并运行：
gcc -o realtime_app realtime_app.c sudo ./realtime_app
请注意，运行实时进程通常需要
root
权限，或者进程拥有CAP_SYS_NICE
能力。
Linux实时进程调度中的SCHED_FIFO与SCHED_RR有何区别？
当我们谈到Linux的实时调度，
SCHED_FIFO（First-In, First-Out）和
SCHED_RR（Round-Robin）总是被拿来比较。从我的经验来看，它们都属于实时调度类别，优先级高于普通的
SCHED_OTHER（也叫
SCHED_NORMAL或
SCHED_TS）进程，但它们在行为上有着关键的不同，这直接影响到你如何选择它们来设计你的实时系统。
SCHED_FIFO，顾名思义，是“先进先出”的。一旦一个
SCHED_FIFO进程被调度器选中并开始运行，它会一直运行下去，直到它主动放弃CPU（例如，通过调用
sched_yield()，或者等待I/O、信号量、互斥锁等），或者被一个更高优先级的实时进程抢占。这意味着，如果一个高优先级的
SCHED_FIFO任务进入了一个计算密集型循环而不主动放弃CPU，它可能会“霸占”CPU很长时间，甚至导致同等优先级或更低优先级的实时任务长时间得不到执行。这种行为对于那些需要连续、不间断执行以满足严格时间要求的任务非常有用，比如某些信号处理、数据采集或控制循环。我个人在处理一些嵌入式系统或工业控制应用时，如果确定任务需要独占性地完成一个周期性工作，
SCHED_FIFO是我的首选。
而
SCHED_RR，即“时间片轮转”，则在
SCHED_FIFO的基础上增加了一个时间片（timeslice）的概念。当一个
SCHED_RR进程被调度执行时，它会在分配给它的时间片内运行。时间片用完后，即使它没有主动放弃CPU，调度器也会将其暂停，并让同等优先级的其他
SCHED_RR进程有机会运行。这就像一个循环队列，每个进程轮流获得CPU时间。这种策略确保了在多个同等优先级的实时任务存在时，它们都能公平地获得CPU资源，避免了某个任务长时间独占CPU的情况。如果你有多个实时任务，它们都需要快速响应但又不能互相长时间阻塞，
SCHED_RR通常是更好的选择。例如，一个需要同时处理多个传感器数据并执行相应控制逻辑的系统，
SCHED_RR可以确保每个传感器处理任务都能及时获得处理。
简而言之，
SCHED_FIFO追求的是“一旦开始，尽量不中断”，适合那些对连续执行有强需求、且任务本身能够合理管理CPU使用率的场景。而
SCHED_RR追求的是“同等优先级下，大家轮流来”，更适合有多个并发实时任务，需要兼顾公平性和响应性的场景。选择哪一个，很大程度上取决于你对任务的实时性要求、任务间的依赖关系以及它们对CPU资源的占用模式。
如何安全地为关键应用配置Linux FIFO实时调度？
为关键应用配置Linux FIFO实时调度，听起来很直接，但实际操作中，如果不加注意，很容易引入新的问题，甚至导致系统不稳定。我通常会强调，这不仅仅是设置一个优先级那么简单，它涉及到系统资源的分配、权限管理以及对潜在风险的规避。
首先，权限管理是基石。默认情况下，非
root用户是无法设置实时调度策略和优先级的。如果你直接尝试，会遇到
EPERM错误。解决办法通常有两个：一是直接以
root用户运行你的应用程序（但这通常不推荐，因为
root权限过大，存在安全隐患）；二是赋予应用程序或用户特定的能力（capabilities）。
CAP_SYS_NICE能力允许进程修改自己的优先级和调度策略。你可以通过
setcap命令来赋予一个可执行文件这个能力：
sudo setcap cap_sys_nice+ep /path/to/your/realtime_app
这样，你的应用程序就可以在非
root用户下设置实时调度了。但请记住，滥用
CAP_SYS_NICE同样危险，因为它赋予了进程影响整个系统调度行为的权力。
其次，资源限制（ulimit
）至关重要。Linux系统通过
ulimit对用户进程的资源使用进行限制，其中就包括实时优先级和内存锁定。要让实时进程稳定运行，你需要确保它能够锁定其所需的内存，防止页面交换（swapping），因为页面交换会引入不可预测的延迟，这对于实时任务是致命的。你需要修改
/etc/security/limits.conf文件，添加或修改以下行：
@your_group hard rtprio 99 @your_group soft rtprio 99 @your_group hard memlock unlimited @your_group soft memlock unlimited
将
your_group替换为你的用户组，
99是允许的最大实时优先级。
memlock unlimited允许进程锁定所有内存。修改后，用户需要重新登录才能使设置生效。
再者，仔细选择优先级。虽然
SCHED_FIFO的优先级范围通常是1-99，但你并不总是需要使用最高的优先级99。过高的优先级可能会导致系统其他关键进程（如网络服务、日志记录、甚至shell本身）得不到CPU时间，从而使系统变得无响应。我的建议是，从一个相对较低但足以满足你实时需求的优先级开始测试，然后逐步提高，直到达到最佳性能。同时，要警惕优先级反转（Priority Inversion）问题，这在实时系统中是一个经典难题，即使是
SCHED_FIFO也无法完全避免。如果一个高优先级的实时任务需要等待一个被低优先级任务持有的资源（如互斥锁），那么高优先级任务就会被阻塞，直到低优先级任务释放资源。这会破坏实时性。解决方案通常是使用支持优先级继承（Priority Inheritance）或优先级上限（Priority Ceiling）的互斥锁（如
pthread_mutex_t配合
PTHREAD_PRIO_INHERIT属性）。
最后，监控和测试不可或缺。配置完成后，务必进行严格的压力测试和实时性验证。使用
latencytop、
ftrace或自定义的计时工具来测量你的实时任务的延迟和抖动。观察系统在重负载下的行为，确保其他非实时任务仍然能够正常运行。一个配置不当的实时进程，可能会让你的系统从一个可靠的工作站变成一个“砖头”。安全配置的关键在于理解其影响，并采取多方面的预防措施。
Linux内核如何管理实时进程的优先级反转问题？
优先级反转（Priority Inversion）是实时系统中一个臭名昭著的难题，即使我们使用了
SCHED_FIFO这样的强实时调度策略，它也可能悄无声息地破坏你的实时性保证。简单来说，优先级反转发生在当一个高优先级的任务（H）需要访问一个被低优先级的任务（L）持有的共享资源（例如，一个互斥锁）时。此时，H任务必须等待L任务释放资源。如果L任务在持有资源期间被一个中等优先级的任务（M）抢占，那么H任务就不得不等待L任务完成，而L任务又被M任务阻塞。结果是，高优先级的H任务实际上被中等优先级的M任务间接阻塞了，这与我们最初赋予H任务高优先级的初衷完全背道而驰。
Linux内核主要通过两种机制来缓解或解决优先级反转问题：优先级继承（Priority Inheritance）和优先级上限（Priority Ceiling）。
优先级继承（Priority Inheritance, PI）是Linux内核中最常用的解决方案，尤其是在
futex（Fast Userspace Mutex）和
rt_mutex（Real-Time Mutex）的实现中。当一个高优先级任务H尝试获取一个互斥锁，而这个锁正被一个低优先级任务L持有，并且L任务的优先级低于H任务时，内核会暂时提升L任务的优先级到H任务的优先级。这样一来，L任务就能够以H任务的优先级运行，尽快地完成它对共享资源的访问，并释放互斥锁。一旦L任务释放了互斥锁，它的优先级就会恢复到原来的值。这种机制确保了持有关键资源的任务不会被优先级更低的任务抢占，从而避免了优先级反转。在
pthread库中，你可以通过设置互斥锁的属性为
PTHREAD_PRIO_INHERIT来启用优先级继承：
#include// ... pthread_mutexattr_t mutex_attr; pthread_mutexattr_init(&mutex_attr); pthread_mutexattr_setprotocol(&mutex_attr, PTHREAD_PRIO_INHERIT); pthread_mutex_init(&my_mutex, &mutex_attr); // ...
这是我在设计需要共享资源的实时应用时，几乎一定会考虑和使用的特性。
优先级上限（Priority Ceiling Protocol, PCP）是另一种解决优先级反转的方法，虽然在Linux内核的通用互斥锁实现中不如优先级继承常见，但在某些特定实时操作系统或RTOS中有所应用。PCP要求每个共享资源（或保护该资源的互斥锁）被赋予一个“优先级上限”，这个上限值通常是所有可能访问该资源的任务中最高优先级的值。当一个任务获取一个互斥锁时，它的优先级会被立即提升到该互斥锁的优先级上限。这样，任何试图抢占这个任务的、优先级低于上限的任务都无法成功，从而避免了优先级反转。与优先级继承不同，PCP在任务获取锁时就提升优先级，而不是等到高优先级任务阻塞时才提升。这可以避免一些潜在的级联阻塞问题，但可能导致不必要的优先级提升。
在实际的Linux实时编程中，我们主要依赖于内核提供的
futex和
rt_mutex机制，这些机制在底层实现了优先级继承。理解这些机制的工作原理，并在应用程序中正确地使用支持优先级继承的同步原语（如
pthread_mutex_t与
PTHREAD_PRIO_INHERIT），是构建健壮、可靠的Linux实时系统的关键。如果忽视了优先级反转，即使你精心设计了调度策略和优先级，你的实时任务也可能在最不合时宜的时候遭遇意想不到的延迟。
