Find the answer to your Linux question:
Results 1 to 4 of 4
what i learnt is that interrupt handlers dont run in process context and cannot be preempted. whan an interrupt handler is called, the interrupts on the current irq is disabled. ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Oct 2010
    Posts
    5

    can interrupt handlers be interrupted by other interrupt handlers


    what i learnt is that interrupt handlers dont run in process context and cannot be preempted.

    whan an interrupt handler is called, the interrupts on the current irq is disabled. if SA_INTERRUPT is not set, other irqs are still active.

    i want to know what happens if another irq y is interrupted when one irq x is being serviced.

    is the current isr x preempted to run isr y ? or the new isr y is called only after the current isr x returns ?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,448
    These are very complex issues and cannot really be given due dilligence in a forum like this. The short answer is that yes, some interrupts can be interrupted by other interrupts (gag - what a sentence!). However, there are non-preemptable interrupts that MUST run to completion of their handler code. When a pre-emptable interrupt is running, and another interrupt occurs that is a higher priority interrupt, then they will "nest", in current parlance. The code for all of this is buried deep in the most fundamental part of the kernel. In any case, how long an interrupt routine runs will demonstrably impact the performance of a system, and can cause lost interrupts, or in the case of real-time systems the missing of a hard deadline. For this, and other reasons, interrupt handlers should be kept as short and simple as possible, generally only setting some flag that other code can detect and then process appropriately. For example, in a serial device interrupt handler, the handler will only check to see if there is data available to read or write, set appropriate flag variables, and then return to the kernel. The driver will then detect this and do the appropriate thing of either reading the data from the device, or writing waiting data to the device.

    So, in the case of your question, if the interrupt handler for irq x is running and an irq y interrupt occurs, the handler for y will behave thusly:

    1. If y is higher priority than x, it will pre-empt x's handler, returning to x's handler when done.
    2. If x is higher priority than y, it will keep running and y's handler will be called when x's is done.
    3. If x is non-preemptable, then it will always run to completion, no matter what other interrupts occur.
    4. If x and y interrupts happen simultaneously, then their priority order is observed. If of the same priority, then it depends upon the OS whether they are run in irq order, or randomized.

    Anyway, this is some of the "rocket science" of operating system engineering.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    Oct 2010
    Posts
    5
    omg that was an awesome explaination. thanks a lot rubberman.

  4. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,448
    Remember, not all operating systems behave the same way. It depends upon their implementation. There used to be a good paper on the QNX web site about their implementation and the behavior of interrupts on their hard real-time operating system. You might find it on QNX Realtime Operating System (RTOS) software, middleware, development tools and services for superior embedded design if you are interested. FYI, the RIM Blackberry tablet that is coming out soon will be run on QNX since RIM bought the company recently.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •