Member Avatar for BestJewSinceJC

What I've learned so far: An OS may trigger a software interrupt by executing a system call. According to what I read online, this is implemented via special instructions such as INT that the CPU can execute. I also understand how interrupts get handled by the interrupt service routine.

My question: since the CPU can only execute one instruction at a time, how does it work? For example, lets say a program X was hogging the CPU resources. The OS would have to execute a software interrupt to regain control of the CPU, but how would it do this (since the CPU is already executing instructions)?

Thanks for any explanations.

  • 3 Contributors
  • 10 Replies
  • 167 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by BestJewSinceJC
Member Avatar for Salem

A real pre-emptive OS would need a clock interrupt (from the outside world) to function.

This would be capable of interrupting "while(1);" and give control back to the OS to decide on something else to do.

Member Avatar for BestJewSinceJC

I get the concept, I just don't understand specifics of how it happens. I'm thinking a possible exam question on my OS test would be something like "what is a system call and how does it work". I can answer the first part, but not the second part. And when you say "from the outside world" that sounds like... a hardware interrupt?

edit:

I just found something that I think will help: something called the "time quantum" and the timer interrupt handler for Linux. It says once the time quantum expires, the process gets preempted... which is something like what I'm looking for, so I think it'll yield some answers. Consider this solved for now, and thanks for the help Salem.

Edited by BestJewSinceJC because: n/a
Member Avatar for nezachem

Salem's answer is correct but it I am afraid it misses the point. An implicit question is "why a system call needs an interrupt?" Why can't an application just call a kernel procedure?

To answer these you have to realize that (a) a kernel procedure may issue privileged instructions not available for the user mode and (b) a kernel address space is usually different from the user's. An interrupt solves both problems since it elevates the execution mode.

The details really depend on a particular architecture.

since the CPU can only execute one instruction at a time, how does it work? For example, lets say a program X was hogging the CPU resources. The OS would have to execute a software interrupt to regain control of the CPU

This is conceptually wrong. It is an application which does a software interrupt to enter into OS.

Edited by nezachem because: n/a
Member Avatar for BestJewSinceJC

This is conceptually wrong. It is an application which does a software interrupt to enter into OS.

My book says there are 3 ways to switch from user mode to kernel mode: an interrupt, a trap, and a system call. Since an interrupt can be only done through hardware, and since my book says a trap is a 'software generated interrupt', which is the same thing it says for a system call . . what does the kernel do if a user application simply refuses to relinquish control of the CPU (as in Salem's case of while(1))? It would seem that the kernel cannot do anything in this case.

edit: I understand the info you've said to me, as I've been reading about that in my book at the same time. The OS has system calls made available so that user programs can ask for services that they otherwise wouldn't be privy to. But it still doesn't answer the question of 'what happens when a process refuses to give up the CPU'.

Edited by BestJewSinceJC because: n/a
Member Avatar for nezachem

My book says there are 3 ways to switch from user mode to kernel mode: an interrupt, a trap, and a system call. Since an interrupt can be only done through hardware, and since my book says a trap is a 'software generated interrupt', which is the same thing it says for a system call

A subtle difference between a software interrupt and a trap is that the latter is an exception (not an interrupt), but in any case them both are synchronous to an application flow. An application stuck in while(1) cannot do either.

. . what does the kernel do if a user application simply refuses to relinquish control of the CPU (as in Salem's case of while(1))? It would seem that the kernel cannot do anything in this case.

True. It cannot do anything. It is not supposed to do anything.

edit: I understand the info you've said to me, as I've been reading about that in my book at the same time. The OS has system calls made available so that user programs can ask for services that they otherwise wouldn't be privy to. But it still doesn't answer the question of 'what happens when a process refuses to give up the CPU'.

An idea of a system call (in any incarnation thinkable) is not about giving up a CPU. It is all about separating OS from an application. Even a single-task OS may (and should, and usually does) provide services in a protected manner.
Now, what a single-task OS is supposed to do when an application refuses to give up the CPU?

Edited by nezachem because: n/a
Member Avatar for BestJewSinceJC

Because the user level application should not have access to the same data and services that the OS does. Hence the OS provides services to the user level application via system calls.

But are you telling me there is no mechanism by which the OS regains control of the CPU if a user application attempts to hog it and not give it back? I wouldn't be so persistent, except that my professor alluded to as much in class. I just haven't been able to figure out what that mechanism is. Of course, the OS could always wait for an application to make a system call, or otherwise wait for an interrupt from I/O etc... but if no such interrupt occurs, the OS should still have a method by which it can regain control of the CPU.

Either way, thanks for your help, you've been helpful clarifying some concepts that were getting a little jumbled in my head.

Edited by BestJewSinceJC because: n/a
Member Avatar for nezachem

But are you telling me there is no mechanism by which the OS regains control of the CPU if a user application attempts to hog it and not give it back? I wouldn't be so persistent, except that my professor alluded to as much in class. I just haven't been able to figure out what that mechanism is.

The OS doesn't need a CPU. It is totally passive. The OS code executes only on behalf of the application process (leaving aside external interrupts). It may "regain control" from an application - only to grant it to another task.
If no task is ready to execute, there's no reason to take the control - there's nobody to give it to.
In fact, the while(1) is a legitimate implementation of a "null task" (on any architecture lacking waiti instruction). The system sits in such a loop until an external event triggers another task ready. At this moment the OS - since it is OS who processes the interrupt - will do the its rescheduling magic. The timeslicing, if implemented, is also a part of this mechanism.

Member Avatar for BestJewSinceJC

Well I appreciate all the info, again, it was helpful in clarifying a few things that I wasn't clear on previously. I finally found the info I was looking for; apparently there is a timer which the OS can schedule which will automatically interrupt any process which runs over its time slice.

Member Avatar for BestJewSinceJC

Yeah, I see that now. I don't know why but I didn't connect the dots until you said that just now. But thanks again for the responses.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.