要让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 %dn", 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: %lldn", counter); // sched_yield(); // 适当放弃CPU，让同等或更低优先级的进程有机会运行 } } return 0;}
编译并运行：
gcc -o realtime_app realtime_app.csudo ./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
是我的首选。
ViiTor实时翻译
AI实时多语言翻译专家！强大的语音识别、AR翻译功能。
116 查看详情 
而
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实时系统的关键。如果忽视了优先级反转，即使你精心设计了调度策略和优先级，你的实时任务也可能在最不合时宜的时候遭遇意想不到的延迟。
以上就是如何在Linux中实时进程 Linux FIFO调度策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/433503.html
微信扫一扫 
支付宝扫一扫 
