Search code examples
linuxserial-portinterruptblockinglatency

What's the longest time that a thread, which is blocking on receiving from an RS232 serial port, can take to wake up?

Assuming I set the process to the highest possible priority and there is no swap...

What's the longest time that a thread, which is blocking on receiving from an RS232 serial port, can take to wake up?

I want to know whether the thread will be woken within microseconds of the UART interrupt hitting the kernel, or whether it will have to wait for the next 100ms timeslice on a CPU.

Solution

  • What's the longest time that a thread, which is blocking on receiving from an RS232 serial port, can take to wake up?

    Depending on the mode (e.g. canonical) a process could wait forever (e.g. for the EOL character).

    I want to know whether the thread will be woken within microseconds of the UART interrupt hitting the kernel, or

    The end of frame (i.e. the stop bit) on the wire is a better (i.e. consistent) reference point.

    "UART interrupt hitting the kernel" is a poor reference point considering interrupt generation and processing can be deferred.
    A UART FIFO may not generate an interrupt for every character/byte.
    The interrupt controller prioritizes pending interrupts, and UARTs are rarely assigned high priorities.
    Software can disable interrupts for critical regions.

    whether it will have to wait for the next 100ms timeslice on a CPU.

    The highest-priority runable process gets control after a syscall completes.
    Reference: 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.

    I'm looking to minimise Linux serial latency between the received stop bit and the start bit of the reply from a high-priority userspace thread.

    I suspected that is what you are really seeking.
    Configuration of the serial terminal is crucial for minimizing such latency, e.g. research the ASYNC_LOW_LATENCY serial flag.
    However configuration of the Linux kernel can further improve/minimize such latency, e.g. this developer reports a magnitude reduction from millisecs to only ~100 microsec.

    I'm only familiar with serial interfaces on ATMEGA and STM32 microcontrollers ...

    Then be sure to review Linux serial drivers.