Linux非阻塞FIFO写入（）定时不一致

我们有一个实时linux用户应用程序，它通过

mkfifo（）

FIFOs（）与同一主机上运行的另一个应用程序通信。我们的应用程序由4个pthread组成，其中一个创建并打开fifo。FIFO以非阻塞（O_非阻塞）模式打开

pthread上的

write（）

到输出FIFO通常需要大约8微秒的时间-这适用于最多2500字节的消息。我们的问题是，偶尔，但有规律地，它需要10倍的时间，很少需要毫秒。发生这种情况时，消息长度不会比平常长

大概是“引擎盖下”发生了什么事情导致了这种情况。有什么办法可以避免吗？如果平均

write（）

时间有所增加，这无关紧要，只要我们没有看到很长的时间

---

感谢您的评论/建议。

我怀疑管道的缓冲区已满，因此作者必须阻止，直到读者将其排出。尝试使用

fcntl

和

F_SETPIPE_SZ

常量增加大小。它是非阻塞的，如果FIFO变满，我们会得到一个错误。所以我们不认为是这样（如果我理解正确的话）。你有没有可能只是遇到Linux不是实时操作系统的事实？系统上其他进程的活动可能会影响任务的时间安排我们已尽力确保情况并非如此。我们使用带有实时扩展的OpenWrt发行版，pthread是使用SCHED_FIFO调度优先级创建的。我们可以看到，当执行write（）的线程正在写入时，它没有被优先级更高的线程之一打断。偶然发现了这个问题：您是否使用cyclictest分析了您的系统？即使在抢占RT下，执行时间也会抖动——但毫秒不应该发生。我怀疑管道的缓冲区已满，所以写入程序必须阻塞，直到读取器耗尽它。尝试使用

fcntl

和

F_SETPIPE_SZ

常量增加大小。它是非阻塞的，如果FIFO变满，我们会得到一个错误。所以我们不认为是这样（如果我理解正确的话）。你有没有可能只是遇到Linux不是实时操作系统的事实？系统上其他进程的活动可能会影响任务的时间安排我们已尽力确保情况并非如此。我们使用带有实时扩展的OpenWrt发行版，pthread是使用SCHED_FIFO调度优先级创建的。我们可以看到，当执行write（）的线程正在写入时，它没有被优先级更高的线程之一打断。偶然发现了这个问题：您是否使用cyclictest分析了您的系统？即使在抢占RT下，执行时间也会抖动——但毫秒不应该发生。