Lets say Unix is executing process A and an interrupt at higher level occurs. Then OS get a interrupt number and from IVT it looks up the routine to call.
Now how does the OS know that this interrupt was for process A and not for process B. It might have been that process B might have issued a disk read and it came back while OS was executing process A.
Thanks
Start with this: http://en.wikipedia.org/wiki/MINIX
Go buy the book and read it; it will really help a lot.
Interrupts aren't "for" processes. They're for devices and handled by device drivers.
The device driver handles the interrupt and updates the state of the device.
If the device driver concludes that an I/O operation is complete, it can then update the its queue of I/O requests to determine which operation completed. The operation is removed from the queue of pending operations.
The process which is waiting for that operation is now ready-to-run and can resume execution.
You are talking about a hardware interrupt and these are not targeted at processes.
If a process A requests a file, the filesystem layer, which already resides in the kernel, will fetch the file from the block device. The block device itself is handled by a driver.
When the interrupt occurs, triggered by the block device, the OS has this interrupt associated with the driver. So the driver is told to handle the interrupt. It will then query which blocks were read and see for what it requested them.
After the filesystem is told that the requested data is ready, it may further process it. Then, the process leaves blocked state.
In the next round of the scheduler, the scheduler may select to wake up this process. It may also select to wake up another process first.
As you can see, the interrupt occurance is fully disconnected from the process operation.
Related
I am teaching myself OS by going through the lecture notes of the course at IIT Bombay (https://www.cse.iitb.ac.in/~mythili/os/). One of the questions in the Process worksheet asks which of the following doesn't always happen in the situation described at the title. The answer is C.
A. The process moves to kernel mode.
B. The program counter of the CPU shifts to the kernel part of the address space.
C. The process is context-switched out and a separate kernel process starts execution.
D. The OS code that deals with handling TCP/IP packets is invoked
I'm a bit confused though. I thought when an interrupt routine occurs the process is context-switched out so other processes can run and the CPU is not idle during that time. The kernel, then, will take care of the packet sending. Why would C not be correct then?
You are right in saying that "when an interrupt routine occurs the process is context-switched out so other processes can run and the CPU is not idle during that time", but the words "generally or mostly" need to be added to it.
In most cases, there is another process waiting for CPU time and that can be scheduled. However it is not the case 100% of the time. The question is about the word "always" and while other options always occur in the given situation, option C is a choice that OS makes at run time. If OS determines that switching out this process can be sub optimal than performing the system call and resuming the same process, then it may not perform the context switching.
There is a cost associated with context switching and if other processes are also blocked on some I/O then it may be optimal for OS to NOT switch the context or there might be other reasons to not switch the context such as what if only 1 process is running, there is no other process to switch the context to!
Suppose we invoke a system call for asynchronous IO. At the time of invoking system call, the mode changes from user mode to kernel mode . After invocation, the mode should immediately change back to user mode so that user application can proceed further(as it is non blocking).
Now if the mode is changed to user mode then how will kernel proceed with IO as mode is changed from kernel to user mode ? Will kernel perform asynchronous IO in user mode ?
IO means two different things (at two different levels of abstractions):
from an application point of view, from a process running in user-mode, calling any system call (listed in syscalls(2) for Linux) related to input or output, e.g. read(2), .... Notice that aio_read(3) is not listed as a system call (it is some library function using other system calls, see aio(7)).
on the raw hardware, any physical input or output operation sending data (or orders) to actual IO devices (e.g. SATA disks, USB ports, etc...)
Asynchronous or synchronous IO for a process means just calling some suitable subset of system calls, since system calls are the only way a process can interact with the kernel, and since in user-mode no physical IO is directly possible.
Read Operating Systems: Three Easy Pieces (freely downloadable) to get a better view of OSes.
Will kernel perform asynchronous IO in user mode ?
This shows some confusion. In practice, inside the kernel, physical IO is generally (and probably always) initiated by interrupt handlers (which might configure some DMA etc...). A hardware interrupt switches the processor to "kernel-mode" (actually supervisor mode of the ISA).
A blocking system call (e.g. read(2) when physical IO is needed since the data is not in the page cache) don't block the entire computer: it is just the calling process which becomes "blocked" so is rescheduled. The kernel will schedule some other runnable process. Much later, after having the kernel handle many interrupts, the blocked process will become runnable and could be rescheduled to run.
Processes are themselves (with files) one of the major abstractions (provided by the kernel) to application code.
In other words, at the conceptual level, the kernel scheduler is coded in some continuation-passing style.
See also kernelnewbies and OSDEV.
The asynchronous IO will be performed on behalf of the process, the kernel will handle it almost as usual while the process continues to run. In blocking mode, the process is just suspended.
Kernel has access to every process space, so he can fill/read data from process user space whatever a process is currently doing.
In a uniprocessor (UP) system, there's only one CPU core, so only one thread of execution can be happening at once. This thread of execution is synchronous (it gets a list of instructions in a queue and run them one by one). When we write code, it compiles to set of CPU instructions.
How can we have asynchronous behavior in software on a UP machine? Isn't everything just run in some fixed order chosen by the OS?
Even an out-of-order execution CPU gives the illusion of running instructions in program order. (This is separate from memory reordering observed by other cores or devices in the system. In a UP system, runtime memory reordering is only relevant for device drivers.)
An interrupt handler is a piece of code that runs asynchronously to the rest of the code, and can happen in response to an interrupt from a device outside the CPU. In user-space, a signal handler has equivalent semantics.
(Or a hardware interrupt can cause a context switch to another software thread. This is asynchronous as far as the software thread is concerned.)
Events like interrupts from network packets arriving or disk I/O completing happen asynchronously with respect to whatever the CPU was doing before the interrupt.
Asynchronous doesn't mean simultaneous, just that it can run between any two machine instructions of the rest of the code. A signal handler in a user-space program can run between any two machine instructions, so the code in the main program must work in a way that doesn't break if this happens.
e.g. A program with a signal-handler can't make any assumptions about data on the stack below the current stack pointer (i.e. in the un-reserved part of the stack). The red-zone in the x86-64 SysV ABI is a modification to this rule for user-space only, since the kernel can respect it when transferring control to a signal handler. The kernel itself can't use a red-zone, because hardware interrupts write to the stack outside of software control, before running the interrupt handler.
In an OS where I/O completion can result in the delivery of a POSIX signal (i.e. with POSIX async I/O), the timing of a signal can easily be determined by the timing of a hardware interrupts, so user-space code runs asynchronously with timing determined by things external to the computer. It's not just an issue for the kernel.
On a multicore system, there are obviously far more ways for things to happen in different orders more of the time.
Many processors are capable of multithreading, and many operating systems can simulate multithreading on single-threaded processors by swapping tasks in and out of the processor.
I want to understand better the signals and interupts mechanism in UNIX OS. As far as I understand it, interrupts are used to communicate between the CPU and the OS kernel. Signals are used to communicate between the OS kernel and OS processes.
I'm having some hard time understanding what happened on certain scenarios, and finding which signals and interrupts are being called and when.
For example, when executing a program and killing it using kill pid. Which interrupts are being triggered when typing the name of the program in the shell (e.g. pluma and then kill pluma_id)?
I've tried to use strace when calling the kill command. The first command that is executed is: execve ("/bin/kill", ["kill", "10057"], [/* 47 cars */]) = 0
As far as I see, this is a standard syscall, but I cannot understand which interrupts were triggered and which signals were sent when the keyboard key-down-event has happened. I also cannot understand which signals were sent to the process when it was killed using the kill syscall (maybe it wasn't sent at all?).
What is the full sequence of events (signals, sisals and interrupts) that happens in the following scenario:
Typing plume in shell
Hitting the enter key and executing pluma
Executing kill pluma_id
(Concise description is more than enough, just to understand the general flow)
Typing plume in shell
Keyboard interrupts occur. The CPU receives the keyboard interrupts, executes the handler, reads the keycode and scan code etc. An event in generated in /dev/input/event* which will be read either by a terminal emulator program or will get forwarded to the program by your input system. Your desktop environment, Xserver etc are involved.
Hitting the enter key and executing pluma
Same as above. Upon receiving the enter key, the shell would fork() and exec() pluma.
Executing kill pluma_id
Shell process makes the kill() system call. My manual for kill says "The default signal for kill is TERM. Use -l or -L to list available signals". There will be a context switch when the system call is made. After verifying the permissions, the kernel would find the process table entry for the specified process ID. It will update the signal mask for the process in the PTE with the signal number pluma has received.
Thus the signal is delivered to the process. Now the process needs to handle the signal. If it has installed a signal handler for the particular signal, the handler gets called. Else a default handeler/action will be taken by the kernel. In unix systems, signal handling for a process usually happens during a context switch, ie, when the process switches back to user context or when the process gets scheduled again.
The Design of the UNIX Operating System by Maurice J. Bach has a very simple and detailed explanation of the whole process. You might want to have a look at it.
Underneath kill (the program) used is a kill() system call, and this system call always gets a signal number as an argument.
The command kill just assumes that certain signals are sent by default, e.g.: TERM signal. What you look at strace output is program invocation. You should look deeper into the trace, and find where the system call is called. And then you'll see a numerical value of the signal.
You should take a look at the kill program documentation I think. It mentions which signal is sent to the process by default, if you don't specify the signal explicitly. It also shows you how to send a specific signal, if you want to.
This comment confuses me: "kill -l generally lists all signals". I thought that a signal means a quantized amount of energy.
[Added] Please, clarify the (computational) signal in Unix and the physical signal. Are they totally different concepts?
[Added] Are there major differences between paradigms? Is the meaning the same in languages such as C, Python and Haskell? The signal seems to be a general term.
I cannot believe that people are not comparing things such as hardware and software or stressing OS at some points.
Comparison between a signal and an interrupt:
The difference is that while
interrupts are sent to the operating
system by the hardware, signals are
sent to the process by the operating
system, or by other processes. Note
that signals have nothing to do with
software interrupts, which are still
sent by the hardware (the CPU itself,
in this case). (source)
Definitions
process = a program in execution, according to the book below
Further reading
compare the signal to Interrupts and Exceptions
Tanenbaum's book Modern Operating Systems
The manual refers to a very basic mechanism that allow processes or the operation system to notify other processes by sending a signal. The operation system can use it to notify programs about abortions of them (signal SIGABRT) or about a segmentation fault (often caused by accessing a null-pointer, SIGSEGV), to name two of them.
Some unix servers use signals so the administrator can use kill to send them a signal, causing them to re-read their configuration file, without requiring them to restart.
There are default actions taken for some signals and other signals are just ignored. For example on receive of a SIGSEGV, the program terminates, while receiving a SIGCHLD, meaning a child-process died, will by default result in nothing special.
There is a ANSI C standard function that installs a signal handler, which is a function that can execute some code when receiving a signal, called signal (read in man signal). In different unix's, that function behave different, so its usage is discouraged. Its manpage refers to the sigaction function (read man sigaction), which behaves consistent, and is also more powerful.
A physical signal and a Unix signal are indeed different concepts. When a Unix signal is sent from one process to another, there is no specific corresponding physical signal. Unix signals are merely an abstraction so programmers can talk about processes communicating with one another.
Unix signals could have been called messages, events, notifications, or even a made-up term like "frobs". The designers just chose the name "signal", and it stuck.
A signal is a message, either to the target process, or to the OS about the target process. It is part of the unix API (and is defined in various POSIX standards).
Read man kill, man signal, and man sigaction.
Other SO questions that might be helpful:
What is the difference between sigaction and signal?
Some from my notes :
Allows asynchronous communication
Between processes belonging to the
same user
From the system to any process
From the system manager to any process
All associated information is in the signal itself
Many different signals
SIGINT
From the system to all processes
associated to a terminal
Trigger: ^C pressed
Usual way to stop a running process
SIGFPE
From the kernel to a single process
Trigger: error in floating point operation
SIGKILL
To a single process
Stops the execution of the destination process
SIGALRM
From the kernel to a single process
Trigger: timer expiration
SIGTERM
To a single process
Recommends the process to terminate gracefully
SIGUSR1, SIGUSR2
From any process to any other
Without a predefined semantic
Freely usable by programmers
Sending a signal to another process
int kill(pid, signal_ID)
The programmer can decide what to do when a signal
is received
Use the default behavior
Ignore it
Execute a user function
Detecting an interrupted write
if (write(fd, buff, SIZE)<0) {
switch (errno) {
case EINTR:
warning(“Interrupted write\n”);
break;
}
}…
A signal is a message which can be sent to a running process.
For example, to tell the Internet Daemon (inetd) to re-read its configuration file, it should be sent a SIGHUP signal.
For example, if the current process ID (PID) of inetd is 1234, you would type:
kill -SIGHUP 1234
A signal is "an event, message, or data structure transmitted between computational processes" (from Wikipedia).
In this case signal means 'message'. So it's sending a message to a process which can tell the process to do various things.
A unix signal is a kind of message that can be sent to and from unix processes. They can do things like tell a process to quit (SIGKILL) or that a process had an invalid memory reference (SIGSEGV) or that the process was killed by the user hitting control-c (SIGINT).
from a *nix command line type in:
man signal
that will should you all the signals available.
Signal is basically an interrupt that tells the process that a particular event has happened.
Signal generally send by the kernel, meanwhile a process can also send the signal to other process (depends on permission ans all ) by using kill and killall command and a process can send signal to itself by using raise.
Major use of signal:
To handle the interrupt.
Process synchronization.
Signal is an interrupt that used to intimate a process that a particular event has happened.
Signal can be send by kernel to running process or one process to another process.
In bash kill and killall command used to send the signal.