Results 1 to 9 of 9

Thread: Hardware Interrupts

  1. #1

    Hardware Interrupts

    Hi

    I'm reading the basics of Hardware Interrupts. One of the statements that I did not understood was, Interrupt-driven devices like, keyboards, pointing devices, network cards etc allows the operating system to get the maximum use out of the processor by overlapping central processing with I/O operations.

    What is overlapping central processing with I/O operations?

    Why does overlapping central processing with I/O operations result in the maximum use of the processor?


    Thanks
    -We May Need To Solve Problems Not By Removing The Cause, But By Designing The Way Forward Even If The Cause Remains In Place-

    Edward de Bono

  2. #2
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    Your questions are first-class - are you preparing for an examn?

    Often, the solution to the problem comes from trying to paraphrase
    badly written text-passages...leading to questions like yours:

    Why is "interrupt-driven" explicitly mentioned? What value does
    an interrupt add to the system? What is the "maximum"? What should
    "overlapping" mean?

    My guess: "overlapping" means that both run simultanously, thus
    "maximum" means that the OS can use all its resources at the
    same time. This certainly is possible if the processor does not
    have to check whether something has occured ("pull"-strategy),
    but is informed that something has occured ("push"-strategy) -
    hence an interrupt is fired.


    But that is my guess ...

    Now my question:
    If my guess is correct - can you plug this together with thread handling
    and thread states, we have discussed/are discussing in another thread[1]?


    Cheers

    P.s. Hopefully, you do not have to paraphrase my guess

    [1] http://www.antionline.com/showthread...hreadid=276349
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  3. #3
    AO Curmudgeon rcgreen's Avatar
    Join Date
    Nov 2001
    Posts
    2,716
    overlapping central processing with I/O operations
    Gotta love the jargon you find in these books. At the lowest level, it isn't true of course.
    Processors don't really do more than one thing at a time, unless they are dual core.
    It has to put its present state on a stack and jump to service the interrupt routine.
    Then it returns to what it was doing.

    I guess the answer is as sec_ware has stated

    if the processor does not
    have to check whether something has occured ("pull"-strategy),
    but is informed that something has occured ("push"-strategy)
    Another way of stating it is "polling vs interrupt"

    http://www.science.unitn.it/~fiorell...lk/node86.html
    I came in to the world with nothing. I still have most of it.

  4. #4
    Originally posted here by sec_ware
    Hi

    Your questions are first-class - are you preparing for an examn?

    Often, the solution to the problem comes from trying to paraphrase
    badly written text-passages...leading to questions like yours:

    Why is "interrupt-driven" explicitly mentioned? What value does
    an interrupt add to the system? What is the "maximum"? What should
    "overlapping" mean?

    My guess: "overlapping" means that both run simultanously, thus
    "maximum" means that the OS can use all its resources at the
    same time. This certainly is possible if the processor does not
    have to check whether something has occured ("pull"-strategy),
    but is informed that something has occured ("push"-strategy) -
    hence an interrupt is fired.


    But that is my guess ...

    Now my question:
    If my guess is correct - can you plug this together with thread handling
    and thread states, we have discussed/are discussing in another thread[1]?


    Cheers

    P.s. Hopefully, you do not have to paraphrase my guess

    [1] http://www.antionline.com/showthread...hreadid=276349

    sec_ware, Thankyou for taking your time for answering my questions. Greatly appreciated.
    All, I'm trying to do is learn fundamentals of how a computer and its hardware works.

    Let me take a guess at your question. Please correct me if I'm wrong.

    Since Threads are an entity within a Process, I would consider them as software related interrupts. Let's say Thread-F is currently in the 'Running' and its Quantum did not end, and the Processor is executing.

    Another thread, Thread-Z has a Higher Priority than Thread-F and has entered the 'Ready' state. This would immediately trigger a software interrupt to the Processor to provide service to Thread-Z.

    So, Thread-Z switches from 'Ready' to 'Running' and Thread-F switches from 'Running' to 'Ready' .

    Is my explanation any close to what you were thinking or am I not even thinking?

    Your question, really made me think. OK, I can atleast understand a little bit of hardware interrupts on a UniProcessor system which has a PIC with 15 Input Lines. I/O device interrupts are fed to the input lines of PIC whose output goes to the Processor. But, what about software related interrupts? Are there Software Interrupt Controllers also? If not, how would a Thread at High Priority and in Ready State Preempt the currently 'Running' Thread and interrupt the Processor to service? What I meant was, just because a Thread is at a Higher Priority and in the Ready State, how would this be communicated to the Processor? [edit:/ I think I found the answer for this question: Kernel Dispatcher]

    /Edit:

    I've just read that interrupts are also given Priorities called IRQLs.

    0 = Normal Thread Execution
    1-2 = Software Interrupts
    3-31 = Hardware Interrupts
    IRQLs 3 to 26 for Devices.

    In the Device Manager, I see the IRQs listed for each device. Where would I find the IRQLs for these devices? Or is it, when a device needs Processor attention, that devices Priority dynamically gets a higher IRQL and transfers control to the interrupt service routine?


    Thanks
    -We May Need To Solve Problems Not By Removing The Cause, But By Designing The Way Forward Even If The Cause Remains In Place-

    Edward de Bono

  5. #5
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    I hope I'm wording this correctly... It's not the thread that decides another thread can do it's "thing". The whole point of a preemptive multitasking OS is that the OS decides which thread runs, when and how long. Compare preemptive multitasking with co-operative multitasking.


    And software interupts are just a machinecode instruction.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  6. #6
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    As SirDice pointed out, preemptive multitasking allows the kernel to
    initiate a context switch (compared to cooperative multitasking, where the
    thread initiates the switch).


    Lateral:Brain-Q you got it right when you mention the kernel dispatcher:
    if a thread switches to a waiting-state (as it occurs within its thread quantum),
    it may be possible that the thread prior to this "flagged" some dispatcher objects
    (an event, an I/O competion port, ...). If a dispatcher objects switches from
    nonsignaled state to the signaled state ("something has occured there"), the
    kernel dispatcher checks, whether a thread in the wait state actually is waiting
    for this "event" to occur. Then, the kernel dispatcher checks the thread priority to
    decide whether the thread should be become running (ie. a context switch occurs).

    Interestingly, depending on the dispatcher object, the thread priority undergoes a
    priority boost (before the kernel dispatcher checks the thread priority). The increase
    in priority can be set for example by the driver[1]. If a thread is waiting for a sound
    device to be ready, the thread will get a priority boost of "8" (recommended value)
    to ensure an uninterrupted "sound-feeling"


    And this was what I meant with my question: if a thread is waiting for a hardware
    interrupt, it may change its state to running, if its current/dynamic thread priority,
    boosted by the hardware interrupt[2], is high enough.


    Cheers

    [1] http://www.microsoft.com/mspress/boo...chap/4354d.asp
    [2] http://www.microsoft.com/whdc/driver/kernel/IRQL.mspx
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  7. #7
    sec_ware, Thankyou for the links. I'm currently reading. In the section under 'Thread Context And Driver Routines', it says,

    From a driver developer’s perspective, however, “thread context” has a broader meaning. For a driver, the thread context includes not only the values stored in the CONTEXT structure, but also the operating environment they define—particularly, the security rights of the calling application. For example, a driver routine might be called in the context of a user-mode application, but it can in turn call a ZwXxx routine to perform an operation in the context of the operating system kernel. This paper uses “thread context” in this broader meaning.


    Let's say a driver routine QwYyy is called by an existing thread, Thread-F and the Thread's Context [what I understand is that the Thread runs under the Security Context of the user-mode application] is of a User-Mode application.

    Now as per above QwYyy in turn calls ZwXxx. Now, my questions:

    Can ZwXxx be called by the Thread-F and be able to have a Thread Context of the Operating System kernel? [which leads me to another question, Can a Thread run under more than one Thread Context?]

    Or

    Will Thread-F spawns a New Thread which will call the ZwXxx and runs in the Thread Context of the Operating System kernel?

    Or

    Will the user-mode application, itself creates a New Thread, which will call ZwXxx and runs in the Thread Context of the Operating System Kernel?

    I apologize, as I've mentioned in a different post, that my comprehension of written English is not so good and that is the reason I've to break up English Paragraphs into examples that I'm able to understand.

    Thanks
    -We May Need To Solve Problems Not By Removing The Cause, But By Designing The Way Forward Even If The Cause Remains In Place-

    Edward de Bono

  8. #8
    Senior Member
    Join Date
    Apr 2004
    Posts
    1,130
    Usually the only way to switch from user-mode to kernel-mode is a "software interrupt" (a.k.a. supervisor call on some archs). Context switch is (again usually) a priviledge instruction; so only kernel mode threads can execute it.

    When you call a kernel program (under your user mode context) and this program needs to switch to kernel mode (i.e. needs to access some special registers or memory areas), this routine will isssue a supervisor call. That call will interrupt the thread and switch to 1st level interrupt handler. 1st level I.H is in kernel mode by default. So, you have switch from user mode to kernel.
    To return from kernel to user, its easier, since kernel can use the priviledge instruction to do that.
    But its architecture theory, it can varies from platform to platform.
    Meu sítio

    FORMAT C: Yes ...Yes??? ...Nooooo!!! ^C ^C ^C ^C ^C
    If I die before I sleep, I pray the Lord my soul to encrypt.
    If I die before I wake, I pray the Lord my soul to brake.

  9. #9
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    We have a thread context (user thread context, system thread context),
    and we have user mode code (ring 3) and kernel mode code (ring 0).

    - A system thread (e.g. PsCreateSystemThread[1], Work Item with IoXxxWorkItem,...) cannot
    execute user mode code, but can execute kernel mode code.
    - A user thread (e.g. CreateThread[2]) can execute both, user mode code, and kernel mode code
    (by sysenter,sysexit,syscall (or even int2e )).


    It is my understanding that the change from ring 3 to ring 0 (and vice versa)
    does not change the thread context.


    If a user thread is requesting some I/O operation, a high-level driver's dispatch routine
    will be called in the context of that user thread. The dispatch routine will forward the
    request to a low-level driver thread in a independent thread context. Until the low-level
    routine has finished its task, the user thread will be in wait state.


    These are your questions and the answers:
    Can ZwXxx be called by the Thread-F and be able to have a Thread Context of the Operating System
    kernel? [which leads me to another question, Can a Thread run under more than one Thread Context?]
    First question: Yes. Per se, the high-level dispatch routine does not have more privileges
    than you do. Hence, you can directly access low-level driver routines and vice versa (not
    trivial!), e.g. based on IOCTL with DeviceIoControl[3]. Here, best practice to do this is, as
    you implied, to use a freshly spawned user thread. But that user thread calls and waits,
    and does not change it thread context.

    Second question: No. A thread runs under one thread context.


    Now, you are diving deep into system programming - and security. From kernel-mode
    drivers it is not too far to kernel-mode rootkits


    Cheers.


    [1] http://msdn.microsoft.com/library/de...3bd235.xml.asp
    [2] http://msdn.microsoft.com/library/de...eatethread.asp
    [3] http://windowssdk.msdn.microsoft.com.../ms680830.aspx
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

Posting Permissions

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