Chapter 3: Processes modified by your instructor.

Chapter 3: ProcessesChapter 3: Processesmodified by your instructormodified by your instructor

3.2 Silberschatz, Galvin and Gagne ©2005Operating System Concepts

Chapter 3: ProcessesChapter 3: Processes

Process Concept

Process Scheduling

Operations on Processes

Cooperating Processes

Interprocess Communication

Communication in Client-Server Systems

This is a very important chapter now that we have completed the introductory materials.

This will require two to three lectures.


Introductory Remarks – Introductory Remarks – Quick Review Concepts SlideQuick Review Concepts Slide

We speak of programs and processes.

It is important to distinguish between the two.

A process is a program in execution; a unit of work.

Programs are files stored somewhere – static and passive

A process is executing and needs resources from the computing system such as

CPU cycles

Memory

Files

I/O devices.

But the operating system is responsible for executing processes and all management of overall resources and those related to processes:

Creation / deletion of user and system processes (user code, system code).

Process scheduling

Synchronization of processes, communication among processes, and the handling of deadlock conditions that can occur among processes.


Process ConceptProcess Concept An operating system executes a variety of programs:

Batch system – jobs

These usually run from beginning to end

Time-shared systems – user programs or tasks

Especially interactive tasking…

Textbook uses terms job and process almost interchangeably (for some systems, this is okay, but not all!)

Process – a program in execution

A process includes:

program counter (contained in a CPU register)

Current register settings

Stack (will see its use ahead)

data section – global variables


Process in MemoryProcess in Memory

Text – the object code instructions

Program Counter – address of the next instructionto be fetched from memory, brought intothe CPU, decoded, and executed

Register settings – current values of working registersStack – temporary area for program parameters,

return addresses, stack frames (used forrecursion) local variables (specific method)

Data – global variables; other data; buffersHeap – (optional) hunk of memory that may be made

available for dynamic storage allocation likefor creation of objects and more

We usually refer to all this as a processes ‘address space.’


Process StateProcess State

As any process executes, it changes state.

All processes have ‘state.’

new: The process is being created

running: Instructions are being executed

waiting: The process is waiting for some event to occur

ready: The process is waiting to be assigned to a process

terminated: The process has finished execution

Even when a process is running, it’s ‘internal’ state is changing! (values of its variables, etc.)


Diagram of Process StateDiagram of Process State

Important to note that at any given instant in time, a CPU can only be executing a single instruction from a user or operating system process.Other processes are in other ‘states’ like waiting or ready, or …

Discuss states and their transitions


Process Control Block (PCB)Process Control Block (PCB) Every process has a PCB – an abstraction of the process itself. Some vendors call PCBs task control blocks (IBM, for example) The PCB is a data structure used to manage the process. It contains: (shown on next slide) everything needed to ‘represent’ the process. Process state – ready, waiting, running, etc. Program counter – address of next instruction CPU registers – instruction registers, stack pointers, index registers, condition-

code and/or flag registers…. CPU scheduling information – scheduling priorities; specific ‘queues’ Memory-management information

Base / limit registers; page tables; segment tables – these depend upon the memory management scheme used

Accounting information – amount of CPU time; memory used, account numbers, time limits, … other resource computations used…

I/O status information – list of I/O devices allocated to the process; list of open files, their status, etc.


Process Control Block (PCB)Process Control Block (PCB)

When a process changes state, say from Running to Wait, the values / contents of the CPU’s registers, instruction counter, etc. are copied into this abstraction of the process to provide for resumption later.

All processes have a PCB to represent them and the resources, constraints, temporary values, etc. associated with the process they represent.

Used to manage the process – resumption of processing, protection of areas of memory, accounting info and much more.


CPU Switch From Process to ProcessCPU Switch From Process to Process

Discuss “ContextSwitching!”

Originating outside or within the process.

Note:

Or some other Ready process!


Process Scheduling QueuesProcess Scheduling Queues Remember: goal of what we call multiprogramming is to have some process

running all the time to maximize CPU utilization;

Goal of time sharing is to switch the context from one process to another so users can interact with each program while it is running.

With a single processor system, only one program can be ‘running’ at any instant in time.

Thus we have a real need of very robust ‘scheduling.’

This can be a very complex undertaking with several queues and algorithms for determining the ‘best’ CPU utilization while providing required services.

We call this the ‘mix’ and refer to this as CPU loading.


Process Scheduling QueuesProcess Scheduling Queues

Job queue – set of all processes in the system

These may likely not be ‘ready’ for execution, but they are in the system and desire to be executed. (have not been made ‘ready’)

Ready queue – set of all processes residing in main memory, ready and waiting to execute; that is, ready for CPU dispatching.

The ‘Ready Queue’ is often implemented as a linked list

Unfortunately, there may be a number of Ready queues (later!)

The Ready-queue header contains a pointer to the first PCB in ready queue.

Other PCBs are linked via a singly-linked forward pointer part of each PCB.

Device queues – set of processes waiting for an I/O device, as you might expect.

Two processes requesting access to the same device will require queueing.

Different data structure may be used to manage different queues; Different searching techniques may be used within different queues to obtain the ‘next’ process. Regular queues, priority queues, etc. may be used ‘here and there.’

Important to note: Processes migrate among the various queues


Observe the Structure of the PCB in LinuxObserve the Structure of the PCB in Linux Of course, Linux (written in C) uses structures. E.g. struct data.

A process’s parent is the process that created it (for multi threading).

A few of the fields are:

pid_t pid; // a unique process identifier (usually integer)

long state; // state of the process

unsigned int time_slide // scheduling info

struct files_struct *files // list of open files (string data)

struct mm_struct *mm // address space of the process

State of the process is in ‘state’ (captured in this PCB)

In Linux kernel, all active processes are presented using a doubly-linked list of task_struct and the kernel maintains a pointer called “current” to the process currently executing.

Good figure in your textbook. Pretty straightforward.


Ready Queue And Various I/O Device QueuesReady Queue And Various I/O Device Queues

Remember from your data structures course that regular queues have items (places in an array, nodes, etc. (PCBs here) inserted into the ‘tail’ and items (PCBs here too) removed (or accessed) from the ‘head’ of the queue.

A regular queue, then, has at least these two pointers: one to the head, and one to the tail.

These ‘headers’ are permanent. But PCBs are created and destroyed as needed.


Representation of Process SchedulingRepresentation of Process Scheduling

Brief look at process schedulingThere are two queues here: a ‘ready queue’ and a ‘device queue.’

When a new process is made ‘ready’ it is put into a ready queue until it is dispatched!

Once dispatched, process may continue until - process requests an I/O - process creates a new sub-process and will now await sub-process termination, or- process could be forcibly removed from CPU via an interrupt and be placed back in ready queue.


SchedulersSchedulers Clearly, a process will migrate among different queues as it continues

along a path of execution until process terminates. But he actual selection of which process to execute is carried out by a

scheduling algorithm.

Long-term scheduler (or job scheduler) – selects which processes should be brought into the ready queue from outside of what is being executed… Particularly useful for batch jobs. Usually these are spooled onto disk ….. Not executed too frequently – maybe even minutes between creation of a

new process The job scheduler controls the degree of multiprogramming, a.k.a. the

number of processes in memory. Ideally, the rate of process termination influences the rate at which the job

scheduler schedules a new job for execution – assuming the job mix is in a stable operation.

(All kinds of parameters in the selection process – ahead)Again, we are after a good ‘mix’ of processes – depending on their ‘characteristics’ to provide for excellent service to users and high CPU utilization and other system resources.


SchedulerScheduler

Short-term scheduler (or CPU scheduler) – selects which process should be executed next and allocates CPU

Processes ‘provided’ to the CPU scheduler via queueing are frequently executed only for a very short time – until they request an I/O, cause a trap, fork a process, etc.

But then these are rapidly placed back into the ‘ready queue’ (CPU queue).

Great care must be taken by the job scheduler in selecting processes ‘into the mix.’

The differences between I/O bound jobs and CPU-bound jobs is incredibly important!

Much more directly ahead on this…


Schedulers (Cont.)Schedulers (Cont.)

Processes can be described as either: I/O-bound process – spends much more time doing I/O than

computations, many short CPU bursts. This means that these jobs may spend a lot of time in a wait queue before

they become ‘ready’ again (once the I/O request has been accommodated. Too many of these in the mix and the CPU becomes idle. This is bad! Ready queue may become empty, and the short-term scheduler (CPU

scheduler) may have little to do. These tend to be business-oriented, file processing, data base jobs.

CPU-bound process – spend more time doing computations; few ‘long’ CPU bursts If the mix contains too many computationally-oriented jobs, the I/O waiting

queue may be empty; I/O devices unused, and system load unbalanced. This too is bad.

These tend to be more scientific or engineering type jobs where there may be a lot of computations rather than lots of input/output.

Systems providing the best overall performance must have a good mix of both I/O bound jobs and CPU-bound jobs in a general purpose processing environment.


More on SchedulersMore on Schedulers

Unix and Microsoft Windows do not have a job scheduler.

Put all input processes into memory for the CPU scheduler.

Stability depends on the physical limitations of the computing system (like number of terminals, devices, etc.).

System can come to a grinding halt too.

Other operating systems may use a medium-term scheduler that may be used to remove processes from memory (and thus for active contention for the CPU) and thus reduce the degree of multiprogramming, but lighten the burden on the operating system and improve throughput should throughput become an issue….

This scheme is called swapping, and the swapped process will be later ‘swapped’ back in.

Discussed in later chapters.


Context SwitchContext Switch When CPU switches to another process, the system must save the state of the old

process and load the saved state for the new process

A very common, typical occurrence on general-purpose computing systems that occurs thousands and thousands of time in a ‘unit’ time..

When getting an interrupt, the system saves the current context of the process being executed (that is, saves its ‘state’).

Its PCB is used to store the interrupted process’s state and all necessary parameters for resumption.

The PCB will be later used resumption.

Changing the CPU from one process to another is called context switching.

Context-switch time is overhead; the system does no useful work while switching

The time it takes for context switching is very hardware dependent.(10 mics…)

Copying register contents to/from memory takes time – not much, but when this is done many thousands of time in a minute, this overhead adds up.

The details of preserving the address space and related issues are discussed in memory management, because the ‘space’ used by the currently executing process may well need to be freed up for some other process(es) – but maybe not.


Shells and the KernelShells and the Kernel

Before we get into Operations on Processes, I want to present a short discussion on Shells and the Kernel.

These may be sometimes confusing…

The Kernel and the Shell


KernelKernel WE know that the kernel is that part of an operating system software where

the real work is done. It performs all those tasks dealing with input and output devices such as managing disk drives, CPU scheduling, memory management, and so very much more..

The Unix kernel is the part of the operating system that contains code for Sharing the CPU and RAM between competing processes Processing all system calls Handling peripherals

The kernel is a program that is loaded from disk into RAM when the computer is first turned on (recall System Boot).

It always stays in RAM and runs until the system is turned off or crashes (or at least ‘most’ of it).

Kernel design and coding must be terribly efficient. is written mostly in C, although some parts are written in assembly

language for efficiency reasons. User programs make use of the kernel via the system call interface, which

we have talked about.


Kernel SubsystemsKernel Subsystems

Kernel facilities are typically divided into five subsystems with specific hunks of functionality for managing each:

Memory management

Process management

Inter-process communications (IPC)

Input/output

File management

These are the facilities / management / control / services that the kernel provides for us as services for both user and system process.

The ‘kernel’ is the ‘big cookie.’


Kernel Subsystems – a view of files and I/O…Kernel Subsystems – a view of files and I/O…

Hierarchically, a view that addresses file management, I/O, and peripherals may appear as:

peripherals

Input/output

File management

And…


Kernel SubsystemsKernel Subsystems

And views at lower level are:

CPU & RAM

Memory Management

Inter-process Communication

Process Management

hardware


Talking to the KernelTalking to the Kernel

Processes access kernel facilities via the system call interface (SCI), and peripherals (special ‘files’) communicate with the kernel via hardware interrupts.

System calls and hardware interrupts are the only ways in which the outside world can talk to the kernel.

Since these are very important, we will devote a lot of time to these in the appropriate sections.

But for now, you may get a visual on this by:


Visual on Talking to the KernelVisual on Talking to the Kernel

Kernel

System Calls

Hardware Interrupts

Process Process Process

peripheral peripheral peripheral

This visual says a great deal!


ShellsShells A shell is a program that sits between you and the raw Unix operating

system.

There are four shells commonly supported by Unix vendors, and we’ve mentioned them in the past. They are the: 1. Bourne shell (sh) 2. Korn shell (ksh) 3. C shell (csh), and the 4. Bourne Again shell (bash).

There is a common core set of operations that make life in the Unix system a little easier and somewhat consistent.

Example: all the shells allow the output of a process to be stored in a file or ‘piped’ to another process. (e.g. $ ls |more )

They also allow the use of wildcards in filenames so its easy to say things like “list all of the files whose names end with the suffix ‘.c’ as in $ ls *.c

Pick your shell. These all work in the same way.


ShellsShells

Shell selection is a matter of taste, power, compatibility, and availability.

Interactive Work: Some feel that the C shell is better than the Bourne shell for interactive work, but slightly worse in some respects for script programming.

Upwards Compatibility: The Korn shell was designed to be upwards compatible with the Bourne shell, and it incorporates the best features of the Bourne and C shell, plus some more features of its own.

Optimal: Bash also takes a ‘best of all worlds’ approach including features from all the other major shells.


Bourne ShellBourne Shell

The Bourne shell comes with absolutely every version of UNIX. The others come with most versions these days, but you might not always find your favorite.

Bash probably ships with the fewest versions of UNIX, but is available for the most.

(Steve Bourne is a personal friend of mine. We work each year together at the ICPC (Inter Collegiate Programming Contest sponsored by IBM). He works with Upsilon Pi Epsilon (UPE) to assist us in annual registration of programming teams.)


Shells – last for nowShells – last for now

It is very simple to change your default login shell, if you wish. You only need to know the full pathnames of the four shells normally, /bin/ksh or /bin/sh, etc.

Each shell’s start up is a wee bit different. Most execute some special start-up file usually in the user’s home

directory that contains some initialization information (some info is usually gotten from

your ‘profile’), displays a prompt, and waits for a user command.

Entering a control-D on a line of its own is interpreted by the shell as ‘end of input’ and causes shell to terminate; otherwise, the shell executes the user’s command.

Bottom line for those interested in the ‘shell game’ is that the shell is essentially an interface to the kernel, where all the work is done.

End of Chapter 3.1End of Chapter 3.1

Chapter 3: Processes modified by your instructor.

Documents

Transcript of Chapter 3: Processes modified by your instructor.