从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？答案

【问题标题】：What's the longest time that a thread, which is blocking on receiving from an RS232 serial port, can take to wake up?从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？
【发布时间】：2020-07-28 06:55:03
【问题描述】：

假设我将进程设置为可能的最高优先级并且没有交换...

从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？

我想知道线程是否会在 UART 中断到达内核后的几微秒内被唤醒，或者它是否必须等待 CPU 上的下一个 100 毫秒时间片。

【问题讨论】：

您的问题结构不佳。挂起并解除阻塞进程的是串行终端驱动程序，而不是 UART 驱动程序。规范与非规范模式是一个因素。该过程可能会永远阻塞等待 EOL。 “UART 中断命中内核” 考虑到中断生成和处理可以延迟，这是一个糟糕的参考。线路上的帧结束（即停止位）是一个更好的参考点。 “是否必须等待下一个 100 毫秒时间片...” -- 不，最高优先级的可运行进程在系统调用完成后获得控制权。
感谢您的评论（我只熟悉 ATMEGA 和 STM32 微控制器上的串行接口，因此我对术语的使用不佳）。如果您写下评论的最后两行作为答案，我会接受。
什么可以延迟中断的产生和处理？可以关掉还是加速？（我希望最大限度地减少接收到的停止位和来自高优先级用户空间线程的回复的开始位之间的 Linux 串行延迟。）

标签： linux serial-port interrupt blocking latency

【解决方案1】：

从 RS232 串行端口接收时阻塞的线程唤醒的最长时间是多少？

根据模式（例如规范），进程可能会永远等待（例如 EOL 字符）。

我想知道线程是否会在 UART 中断到达内核后的微秒内被唤醒，或者

线路上的帧结束（即停止位）是一个更好的（即一致的）参考点。

“UART 中断命中内核”考虑到中断生成和处理可以延迟，是一个糟糕的参考点。
UART FIFO 可能不会为每个字符/字节生成中断。
中断控制器优先处理挂起的中断，UART 很少被分配高优先级。
软件可以禁用关键区域的中断。

它是否必须在 CPU 上等待下一个 100 毫秒时间片。

系统调用完成后，最高优先级的可运行进程获得控制权。
参考：Linux Kernel Development: Preemption and Context Switching：

Consequently, whenever the kernel is preparing to return to user-space, either 
on return from an interrupt or after a system call, the value of need_resched 
is checked. If it is set, the scheduler is invoked to select a new (more fit) 
process to execute.

我希望最大限度地减少接收到的停止位和来自高优先级用户空间线程的回复的开始位之间的 Linux 串行延迟。

我怀疑这就是你真正想要的。
串行终端的配置对于最小化这种延迟至关重要，例如研究 ASYNC_LOW_LATENCY 串行标志。
然而，Linux 内核的配置可以进一步改善/最小化这种延迟，例如this developer reports 幅度从毫秒减少到仅约 100 微秒。

我只熟悉 ATMEGA 和 STM32 微控制器上的串行接口...

那么请务必查看 Linux serial drivers。

【讨论】：