Source : Stallings Book and Bach's book
There are two categories of process: system process and user process. System process take care of administrative task that OS needs to perform (so we ignore them for time being) and they always run in kernel mode. The user process can run in user mode to execute user programs and in kernel mode to execute system calls. A user process enters kernel mode by issuing system calls.
What are the state of Process?
There are a total of nine states.
User Running: Executing in user mode.
Kernel running: Executing in kernel mode.
Ready to Run, in memory: Ready to run as soon as kernel schedules it.
Asleep in memory: Unable to execute until an event occurs, process is in main memory.
Ready to run, swapped: Process is ready to run, but the swapper should swap it to main memory before the kernel can schedule it.
Sleeping, swapped: The process is awaiting an event, and has been swapped to secondary storage.
Preempted: Process is returning from kernel to user mode, but the kernel preempts it and does a process switch to schedule another process.
Created: Newly created and not ready to run.
Zombie: Process no longer exists, but it leaves a record for its parent process to collect.
The main features are summarized here:
UNIX employs two running state indicating whether the process is executing in user or kernel mode.
A distinction is made between two states, ready to run in memory and Preempted. They are essentially the same states. When a process is running in kernel mode (e.g. as a result of clock interrupt or I/O interrupt), there will come a time when the kernel has completed its work and is ready to return control to the user program. At this time the kernel may decide to preempt this process, in favor of a higher priority process in the ready to run in memory process. In that case the current process moves to Preempted state. However for the purpose of dispatching those processes in the preempted state and ready to run in memory state form the same queue.
Preemption occurs only when a process is moving from kernel to user mode. Preemption cannot occur in kernel mode. This makes UNIX unsuitable for real time processing.
Process Description (or Data Structure)
Process image is organized in three parts: user-level context, register context, and system-level context.
User-Level Context: Consists of user programs and can be generated from the compiled object file. User program is separated into text and data. Text area is read only (i.e. the program), and data is the data that program needs. User stack is used for procedure calls etc. There is a shared space. Physically it is just one area for all process, i.e. there is only one copy of it, but because of virtual memory it appears to each sharing process that the shared memory region is in its address space When a process is not running, the process status information is stored in the register context..
Register Context Area:
System Level Context: This is the remaining part that OS needs to manage the process. There are two parts: static and dynamic. Static part consists of process table entry - this information is always accessible to OS (Process table entry consists of information about current state of process, process ids, priority, memory status - its in main or swapped out, pointer to next link in the ready Q.) There is the U Area Context, that kernel needs when executing a process in the context of the user. The third static portion is the per process region table - that defines the mapping from virtual to physical address space, as well the permissions e.g. read only. The last thing is the kernel stack, i.e. the dynamic part. This stack is used when the process is executing in the kernel mode, and it contains the information that must be saved and restored as procedure calls and interrupts occur.
Operations in Process:
Process creation is done using fork. The following is done when fork is done:
(All this happens in kernel mode of the parent process)
Allocates a slot in process table for the new process.
Assign a Unique process ID to the child
makes a copy of the process image of the parent, with the exception of any shared memory.
it increments the counters for any files owned by the parent, to reflect that additional process owns that file.
assigns the child process to ready to run state.
it returns the ID number of the child to parent and a value of 0 to the child process.
Once this is done then the following happens.
Stay in parent process, but the control is returned to user mode now.
Transfer control to child - and child process start executing the next statement after the return of the fork.
Transfer control to another process.