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
   414   415   416   417   418   419   420   421   422   423   424