Page 419 - DCAP103_Principle of operating system
P. 419
Principles of Operating Systems
Notes kill system call allows a process to signal another related process. The choice of the name ‘’kill’’
for this system call is not an especially good one, since most processes send signals to other ones
with the intention that they might be caught. For many real-time applications, a process needs to
be interrupted after a specific time interval to do something, such as to retransmit a potentially
lost packet over an unreliable communication line. To handle this situation, the alarm system
call has been provided. The parameter specifies an interval, in seconds, after which a SIGALRM
signal is sent to the process. A process may have only one alarm outstanding at any instant. If an
alarm call is made with a parameter of 10 seconds, and then 3 seconds later another alarm call
is made with a parameter of 20 seconds, only one signal will be generated, 20 seconds after the
second call. The first signal is cancelled by the second call to alarm. If the parameter to alarm is
zero, any pending alarm signal is cancelled. If an alarm signal is not caught, the default action
is taken and the signaled process is killed. Technically, alarm signals may be ignored, but that
is a pointless thing to do.
It sometimes occurs that a process has nothing to do until a signal arrives. For example, consider
a computer-aided instruction program that is testing reading, speed and comprehension. It
displays some text on the screen and then calls alarm to signal it after 30 seconds. While the
student is reading the text, the program has nothing to do. It could sit in a tight loop doing
nothing, but that would waste CPU time that a background process or other user might need.
A better solution is to use the pause system call, which tells Linux to suspend the process until
the next signal arrives.
Give the command write file in the Linux operating system.
14.2.3 Implementation of Processes and Threads in Linux
A process in Linux is like an iceberg that what you see is the part above the water, but there is
also an important part underneath. Every process has a user part that runs the user program.
However, when one of its threads makes a system call, it traps to kernel mode and begins running
in kernel context, with a different memory map and full access to all machine resources. It is
still the same thread, but now with more power and also its own kernel mode stack and kernel
mode program counter. These are important because a system call can block part way through,
for example, waiting for a disk operation to complete. The program counter and registers are
then saved so the thread can be restarted in kernel mode later.
The Linux kernel internally represents processes as tasks, via the structure task struct. Unlike
other OS approaches, which make a distinction between a process, lightweight process and thread,
Linux uses the task structure to represent any execution context. Therefore, a single-threaded
process will be represented with one task structure; a multi-threaded process will have one task
structure for each of the user-level threads. Finally, the kernel itself is multi-threaded, and has
kernel level threads which are not associated with any user process and are executing kernel
code. We will return to the treatment of multi-threaded processes (and threads in general) later
in this section. For each process, a process descriptor of type task_ struct is resident in memory
at all times. It contains vital information needed for the kernel’s management of all processes,
including scheduling parameters, lists of open file descriptors, etc. The process descriptor along
with memory for the kernel-mode stack for the process are created upon process creation.
For compatibility with other UNIX systems, Linux identifies processes via the Process Identifier
(PID). The kernel organizes all processes in a doubly linked list of task structures. In addition
to accessing process descriptors by traversing the linked lists, the PID can be mapped to
the address of the task structure, and the process information can be accessed immediately.
412 LOVELY PROFESSIONAL UNIVERSITY