If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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-

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]?

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)

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]?

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.

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-

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.

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.

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-

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.

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