computer science 4500 operating systems -...

41
1 Slide 1 Computer Science 4500 Operating Systems Module 3 The Process Model, Threads, and Interprocess Communication Operating Systems © 2008 Stanley A. Wileman, Jr. Updated 7/21/2014 In This Module… The Process Model Process States Threads Interrupts, Traps and Signals Interprocess Communication Race Conditions Solutions to the Mutual Exclusion Problem Slide 2 Operating Systems © 2008 Stanley A. Wileman, Jr.

Upload: doanxuyen

Post on 06-Apr-2018

214 views

Category:

Documents


1 download

TRANSCRIPT

1

Slide 1

Computer Science 4500Operating Systems

Module 3

The Process Model, Threads, andInterprocess Communication

Operating Systems© 2008 Stanley A. Wileman, Jr.

Updated 7/21/2014

In This Module…

The Process Model

Process States

Threads

Interrupts, Traps and Signals

Interprocess Communication

Race Conditions

Solutions to the Mutual Exclusion Problem

Slide 2Operating Systems© 2008 Stanley A. Wileman, Jr.

2

The Process Model

Even in single user systems, more than onepotentially unrelated program may need to beactive at the same time.

This gives the effect of parallel execution ofthe programs, or pseudoparallelism.

A process is the encapsulation of allinformation about a running program,allowing the CPU to be switched betweenthem.

Slide 3Operating Systems© 2008 Stanley A. Wileman, Jr.

Why Use Multiple Processes?

One advantage of multiple processes is thatthere may be more processes available touse the processor(s). This increases theprobability that the processor(s) will be active(better resource use).

In general, choose multiple processes whenA significant amount of overlap between theprocesses can be achieved.

The application is too complex to develop as asingle process, or it would be too complex anddifficult to maintain.

Slide 4Operating Systems© 2008 Stanley A. Wileman, Jr.

3

Disadvantages of Multiple Processes

With more processes there is likely moreoverhead time and more resourceconsumption by the operating system. Thisoverhead does not directly contribute to theprocessing needed by the application.

Increased programmer effort is also neededto coordinate the multiple processes andprovide for communication between them.

Slide 5Operating Systems© 2008 Stanley A. Wileman, Jr.

Process and Program Timing

If a CPU is dedicated to running a singleprogram/process, then it runs at the fullspeed of the processor.

If multiple processes are running, then theCPU is switched (rapidly) between theprocesses; each process gets only a fractionof the CPU’s time.

Most programs are not time-critical, and sothe process model is acceptable.

Slide 6Operating Systems© 2008 Stanley A. Wileman, Jr.

4

Review: Programs and Processes

A program is a static set of instructions anddata for a processor.

A process is the activity of a CPU in carryingout the instructions in a program.

Input/output state, quotas, privileges,register contents, and so forth are associatedwith a process, not a program.

Slide 7Operating Systems© 2008 Stanley A. Wileman, Jr.

Process Hierarchies

A process can create additional processes(using fork() or a similar system call).

A new process is called a child process of theparent process that created it.

Child processes can create their own childprocesses to an arbitrary depth (dependenton quotas and other system resources).

This results in a tree-structured hierarchy ofprocesses in a system.

Slide 8Operating Systems© 2008 Stanley A. Wileman, Jr.

5

System Services, or OS APIs

System services are those functions providedby the operating system to applications.

They are frequently requested (or invoked)using instructions like INT (x86) or SVC(IBM) in assembly language.

Most modern operating systems are notwritten in assembler (but some functions areusually in assembler since high levellanguages don’t provide the necessaryfeatures).

Slide 9Operating Systems© 2008 Stanley A. Wileman, Jr.

Libraries and Direct System Calls

Most high-level languages include libraries offunctions for use by applications.

Some of these functions make it simpler toinvoke system services than by directlyinvoking them from assembler language.

Example: MS Windows includes theCreateProcess system service; the Clibrary includes the spawn function whichinvokes the CreateProcess system service.

Slide 10Operating Systems© 2008 Stanley A. Wileman, Jr.

6

Windows CreateProcess System Service

CreateProcess (ImageName,CommandLine,

ProcessSecurity, ThreadSecurity,

InheritHandlesFlag,CreationFlags,

Environment, CurrentDirectory,

StartupInfo, ProcessInfo);

10 Parameters are needed with this call tocreate a new process!

Slide 11Operating Systems© 2008 Stanley A. Wileman, Jr.

Windows _spawnvp Library Function

_spawnvp(mode, commandname, argv);

mode is _P_WAIT if the parent waits for the childto terminate, or _P_NOWAIT if the parent

proceeds in parallel with the child.

Commandname is the name of the file containingthe executable code, and argv is an array of

pointers to parameters.

Note that only three arguments are needed here!

Slide 12Operating Systems© 2008 Stanley A. Wileman, Jr.

7

Process States

During their lifetime, processes will alwaysexist in one of three states: running, ready,or blocked.

The state of a process is determined by theoperating system, and is recorded in itsprocess table entry.

Many factors can affect the state of aprocess, but there are some generalcharacteristics of each state.

Slide 13Operating Systems© 2008 Stanley A. Wileman, Jr.

Process States: Running

Running

A process in the running state is currently beingexecuted by a CPU; the process has all necessaryresources required for execution.© 2008 Stanley A. Wileman, Jr. Slide 14Operating Systems

8

Process States: Ready

A process in the ready state has all necessaryresources required for execution except the CPU.

Ready

Running

© 2008 Stanley A. Wileman, Jr. Slide 15Operating Systems

Process States: Blocked

A process in the blocked state is not capable of beingexecuted because one or more required resources areunavailable. The process is said to be waiting on aresource, blocked, or sleeping.

Ready

Running

Blocked

© 2008 Stanley A. Wileman, Jr. Slide 16Operating Systems

9

Process State Summary

Running: currently being executed by aCPU, and has all necessary resourcesrequired for execution.

Ready: has all necessary resources requiredfor execution except the CPU.

Blocked: not capable of being executedbecause one or more required resources areunavailable. The process is said to be waitingon a resource, blocked, or sleeping.

Slide 17Operating Systems© 2008 Stanley A. Wileman, Jr.

Process State Transitions

Processes are moved between states bycomponents of the operating system inresponse to system conditions and processactions.

There are four transitions of interest:

Ready to running

Running to blocked

Blocked to ready

Running to ready

Slide 18Operating Systems© 2008 Stanley A. Wileman, Jr.

10

Process State Transitions:Ready to Running

A process is moved from ready to running when aCPU is available (idle), and the scheduler selects itfor execution from the set of ready processes.

Ready

Running

Blocked

© 2008 Stanley A. Wileman, Jr. Slide 19Operating Systems

Process State Transitions:Running to Blocked

A process is moved from running to blocked whenit requests exclusive use of an unavailableresource.

Ready

Running

Blocked

© 2008 Stanley A. Wileman, Jr. Slide 20Operating Systems

11

Process State Transitions:Blocked to Running

A process is moved from blocked to ready whenthe resource on which it was waiting is madeavailable.

Ready

Running

Blocked

© 2008 Stanley A. Wileman, Jr. Slide 21Operating Systems

Process State Transitions:Running to Ready

A process is moved from running to ready, or preempted, whenthe operating system decides another process should be run, orthe process voluntarily relinquishes its use of the CPU.

Ready

Running

Blocked

© 2008 Stanley A. Wileman, Jr. Slide 22Operating Systems

12

Process State Transitions: Summary

Ready to running: the scheduler selects theprocess to run on an idle CPU

Running to blocked: the process requestsexclusive use of an unavailable resource

Blocked to ready: the resource on which theprocess was waiting becomes available

Running to ready: the operating systemdecides another process should be run, or theprocess voluntarily relinquishes the processor.

Slide 23Operating Systems© 2008 Stanley A. Wileman, Jr.

Blocking: Running to BlockedA process blocks when it cannot proceed becauseit needs exclusive use of a resource that is notimmediately available.

Examples: A read system call can result in aprocess blocking until the requested data isobtained. An explicit time delay blocks theprocess requesting the delay.

Resources that can be provided quickly don’tresult in blocking (for example, additionalmemory, or the current time of day).

A blocked process is often said to be sleeping.Slide 24Operating Systems© 2008 Stanley A. Wileman, Jr.

13

Process Preemption: Running to Ready

A process can (in many operatingsystems) voluntarily relinquish its use ofthe CPU, or it may be forcibly removedfrom the running state.

A scheduler may preempt a processbecause it’s had its “fair share” of the CPUtime (quantum), or because a higherpriority process is ready to execute.

Slide 25Operating Systems© 2008 Stanley A. Wileman, Jr.

Scheduling: Ready to Running

A process is allowed to execute when thescheduler selects it from among the pool ofready processes.

Many different scheduling algorithms areused in operating systems, including roundrobin, priority, and shortest job first. We willdiscuss some of these later in the course.

Moving a process between the ready andrunning states requires a context switch.

Slide 26Operating Systems© 2008 Stanley A. Wileman, Jr.

14

Unblocking: Blocked to Ready

A process moves from the blocked tothe ready state when the resource(s)for which it was waiting becomesavailable.

No context switch is necessary when aprocess moves from the blocked to theready state.

Slide 27Operating Systems© 2008 Stanley A. Wileman, Jr.

Process Tables

The state of each process and otherrelated information is stored in an entryin the process table.

The process table entries may bearranged in a linked list or an array.

Process table entries contain variousinformation, depending on theoperating system.

Slide 28Operating Systems© 2008 Stanley A. Wileman, Jr.

15

Example Process Table (from NetBSD)struct proc {

struct proc *p_forw; /* Doubly-linked queue - blocked procs */

struct proc *p_back;

struct proc *p_next; /* Linked list of active procs */

struct proc **p_prev; /* (ready) and zombies. */

struct pcred *p_cred; /* Process owner's identity. */

struct filedesc *p_fd; /* Ptr to open files structure. */

struct pstats *p_stats; /* Accounting/statistics*/

struct plimit *p_limit; /* Process limits. */

struct vmspace *p_vmspace; /* Address space. */

struct sigacts *p_sigacts; /* Signal actions, state */

pid_t p_pid; /* Process identifier. */

struct proc *p_pgrpnxt; /* Pointer to next proc in proc grp. */

struct proc *p_pptr; /* Ptr to process structure of parent. */

struct proc *p_osptr; /* Pointer to older sibling processes. */

struct proc *p_ysptr; /* Pointer to younger siblings. */

struct proc *p_cptr; /* Pointer to youngest living child. */

u_int p_estcpu; /* Time averaged value of p_cpticks. */

int p_cpticks; /* Ticks of cpu time. */

fixpt_t p_pctcpu; /* %cpu for this process */

. . .Selected fields only

© 2008 Stanley A. Wileman, Jr. Slide 29Operating Systems

Interrupts

An interrupt is a mechanism used by thecomputer hardware to indicate that an eventrequires the CPU’s attention. For example,the completion of a disk read will usuallycause the generation an interrupt.

Interrupts are asynchronous with CPUprocessing because they may be generated atany time, even during the processing of aninstruction.

The event being reported may have nothingto do with the currently running process.

Slide 30Operating Systems© 2008 Stanley A. Wileman, Jr.

16

Interrupt Characteristics

Interrupts usually have associated priorities,with faster and more important devices havinghigher priority interrupts.

Interrupts may be masked, meaning that theCPU has elected to ignore receiving the interruptindication at the current time. The interruptdoesn’t disappear, but is simply ignored.

Interrupts may also be globally disabled, whichmeans that no (or almost no) interrupts will berecognized by the processor.

Slide 31Operating Systems© 2008 Stanley A. Wileman, Jr.

Interrupt and Masking Analogy

Assume your child has just been stung by a beein your yard. You rush outside to help, puttingwhatever you were doing “on hold.”

Assume then that the telephone rings.

You will probably ignore (mask) the interruptionfrom the ringing telephone, because dealing withthe bee sting interrupt is of higher priority. If it’sstill ringing, you may later answer it after dealingwith the bee sting.

Later you return to what you were doing.

Slide 32Operating Systems© 2008 Stanley A. Wileman, Jr.

17

Interrupt Handlers

An interrupt handler is the code moduleexecuted as a result of an interrupt.

There is usually a separate interrupthandler for each type of device that cangenerate an interrupt.

Interrupt handlers are not part of aprocess, and may not block.

Slide 33Operating Systems© 2008 Stanley A. Wileman, Jr.

Interrupt Vectors

Most computer hardware determines thelocation of the interrupt handler bylooking in an interrupt vector (an array).

Each entry contains information aboutthe location of the interrupt handler (thatis, a new program counter value), andperhaps other information.

Slide 34Operating Systems© 2008 Stanley A. Wileman, Jr.

18

TrapsTraps are similar to interrupts, but occursynchronously with processing by the CPU.

Traps may be generated for many reasons,including executing a system call, or an attemptto execute a privileged instruction, accessprotected memory, or divide by zero.

Traps are always generated by the runningprocess, and cannot normally be blocked ormasked (like interrupts).

UNIX systems usually translate traps into signalsthat are delivered to the process.

Slide 35Operating Systems© 2008 Stanley A. Wileman, Jr.

Handling an Interrupt1. The interrupt (if not blocked) occurs and is reported to the CPU, usually

only after the completion of the current instruction.

2. The hardware saves some CPU registers (typically on a stack).

3. The program counter (and perhaps other registers) are set from apredefined location in the interrupt vector.

4. The remaining volatile registers are saved by software.

5. A new stack is established.

6. The interrupt handler processes the interrupt (perhaps starting I/O)and possibly unblocks a process.

7. The scheduler may intervene to select a new process to execute.

8. A context switch may take place, and the new process begins/resumesexecution.

Slide 36Operating Systems© 2008 Stanley A. Wileman, Jr.

19

Handling a Trap1. The trap occurs and is reported to the CPU, synchronously with the

execution of the current instruction.

2. The hardware saves some CPU registers (typically on a stack).

3. The program counter (and perhaps other registers) are set from apredefined location determined by the trap type (e.g. divide by zero,illegal instruction).

4. The remaining volatile registers are saved by software.

5. A new stack might be established, if necessary.

6. The trap handler processes the trap, usually arranging for a signal tobe sent to the process.

7. The process that generated the trap may continue (to handle the signaldelivery), or a different process may be selected to run.

Slide 37Operating Systems© 2008 Stanley A. Wileman, Jr.

Signals

A signal is the user-level softwarecounterpart of a hardware-levelinterrupt or trap.

Signals are delivered to processes whencertain events occur. Some of theseevents correspond to traps that arereported to the operating system.

Slide 38Operating Systems© 2008 Stanley A. Wileman, Jr.

20

Signal Example

The simple program shown in the nexttwo slides (see zdiv.c on loki) illustratessome essentials of signals and signalhandling.

First the program asks if you want touse a signal handler. Then an integer(k) is read, and 4 / k is computed.

Note what happens if k is 0.

Slide 39Operating Systems© 2008 Stanley A. Wileman, Jr.

main(){int k, ans, c;printf("Use a signal handler (y or n)? ")c = getchar();if (c == 'y') {

printf("We will use a signal handler for SIGFPE.\n");signal (SIGFPE, sigh); /* setup handler for SIGFPE */

} else if (c == 'n') {printf(”We won't use a signal handler for SIGFPE.\n");

} else {printf ("You must answer y or n.\n");exit(1);

}printf("Enter an intger k. We will compute 4 / k.\n");printf("k = ");scanf("%d",&k);ans = 4 / k; /* SIGFPE will occur if k == 0 */printf("4 / k = %d\n", ans);exit(0);

}

© 2008 Stanley A. Wileman, Jr. Slide 40Operating Systems

21

#include <stdio.h>#include <stdlib.h>#include <signal.h>/*---------------------------------------------------------*//* The function sigh is the signal handler. It should have *//* void return type and a single integer parameter (which *//* will receive the signal number. *//*---------------------------------------------------------*/void sigh (int signum){

printf("Signal %d was delivered to us.\n”, signum);printf("But we are still in control!\n");exit(1);

}

© 2008 Stanley A. Wileman, Jr. Slide 41Operating Systems

ThreadsA thread, sometimes called a lightweight process, isconceptually similar to a process in that it representsa separately scheduled unit of work for a CPU.

A thread has some private memory and its own setof CPU registers, including the program counter, butshares all other resources (memory, quotas, etc.)with all other threads belonging to the sameprocess.

In systems with threads, the process can beconsidered the owner of the resources (memory,etc.) while the threads represent the units ofexecution.

Slide 42Operating Systems© 2008 Stanley A. Wileman, Jr.

22

When to Use ThreadsThreads are appropriate tools to usewhen multiple independentcomputations require access to thesame address space.

Example: multiple sensors need to besampled at different intervals, but thesamples thus obtained need to bestored in a single data structure inmemory.

Slide 43Operating Systems© 2008 Stanley A. Wileman, Jr.

Thread Implementations

Threads are commonly implemented either asintegral parts of the operating system kernelor as user-level library functions.

In kernel implementations, kernel interventionis required on every switch between threads,even between those in the same process.

In user-level implementations, the kernel isnot aware of threads, and may block anentire process even though other threads inthe process could run.

Slide 44Operating Systems© 2008 Stanley A. Wileman, Jr.

23

Complications with Threads

On a fork call, does the child get as manythreads as the parent, including blockedthreads?

What happens if application library functionsare not reentrant?

How are detailed error reports provided?Recall a single errno variable is used forUNIX processes.

To which thread is a signal delivered?

To which thread is a input report delivered?Slide 45Operating Systems© 2008 Stanley A. Wileman, Jr.

Common Thread Implementations

POSIX (IEEE standard Portable Operating SystemInterface) — Pthreads — available for numeroussystems (including Linux, OS X, and Windows).

Mach threads — found in OSF/1 and Digital UNIX

Win32 — implemented in Microsoft Windows

Slide 46Operating Systems© 2008 Stanley A. Wileman, Jr.

24

Interprocess Communication (IPC)

Processes (and threads) need to be ableto communicate with each other toachieve synchronization, share data, etc.

Many different techniques have beendevised to effect this communication.

Even unrelated processes may need tosynchronize their access to sharedresources.

Slide 47Operating Systems© 2008 Stanley A. Wileman, Jr.

Race Conditions

Processes that use shared resources must becareful to ensure that modifications to thoseresources are done in a consistent manner.

We use the term atomic to refer to anoperation on a shared resource that must becompletely performed by a process beforeany other process can use the resource.

Failing to guarantee atomic execution canresult in inconsistent results. This potential iscalled a race condition.

Slide 48Operating Systems© 2008 Stanley A. Wileman, Jr.

25

A Simple Race Condition Example

Suppose we have two threads in a process,each of which has access to a global integervariable Z; Z is initially zero.

Each thread is very simple. It performs afixed number of repetitions of a loop. Insidethe loop, the variable Z is first incremented(by 1), then it is decremented (by 1).

When both threads have finished, what is theexpected value of Z? (Compile/run race.c)

Slide 49Operating Systems© 2008 Stanley A. Wileman, Jr.

How to Increment or Decrement

Depending on processor architecture,incrementing or decrementing a variable can bedone in various ways.

Some processors may have specific instructionsto increment or decrement a variable stored inRAM.

Other processors may need to copy the variableto a register, increment or decrement theregister, and then store the result back intoRAM.

Slide 50Operating Systems© 2008 Stanley A. Wileman, Jr.

26

Specific Code Example (x86)

Slide 51Operating Systems© 2008 Stanley A. Wileman, Jr.

Here is specific code for increment and decrement generated bythe C compiler on a Linux system. The movl instruction is usedto move (copy) a value from one place to another. Z(%rip)is areference to a memory-based volatile variable Z, and %eax is aprocessor register. The addl and subl instructions should be

obvious. (Use –S option with gcc to generate assembler code).

movl Z(%rip), %eaxaddl $1, %eaxmovl %eax, Z(%rip)movl Z(%rip), %eaxsubl $1, %eaxmovl %eax, Z(%rip)

And the Answer Is…

The result in Z could be zero, or itcould be non-zero.

Clearly the desired result should bezero.

Can you see how these results could beobtained? Consider all of the possiblesequences that could be used by aprocessor in executing the code shownin the previous slide.

Slide 52Operating Systems© 2008 Stanley A. Wileman, Jr.

27

Situations like this, involving unconstrainedaccess by two or more processes (or threads)to shared resources, result in race conditions.

Race conditions are usually difficult to detect,since they may depend on execution timing(which may differ between runs).

The only feasible solution to race conditions isto properly design the programs tosynchronize access to the shared dataresources.

The Moral of the Story…

Slide 53Operating Systems© 2008 Stanley A. Wileman, Jr.

Critical Sections

The region of a program in which a sharedresource is accessed is called a critical section.

Avoiding race conditions requires guaranteeingmutual exclusion between the critical sectionsreferencing the same shared resource.

Other conditions must hold for a good solutionto the race condition problem.

The program nrace.c shows one solution to therace condition.

Slide 54Operating Systems© 2008 Stanley A. Wileman, Jr.

28

Race Condition Solution Requirements:

1. No two processes may be simultaneouslyinside their critical sections.

2. No assumptions may be made about thespeeds of, or the number of CPUs.

3. No process running outside its criticalsection may block other processes.

4. No process should have to wait forever toenter its critical section once it has indicatedits desire to do so.

Slide 55Operating Systems© 2008 Stanley A. Wileman, Jr.

Developing Solutions

In the remainder of this module we willconsider the efforts that have been made tosolve the mutual exclusion problem, includingthose that are successful and unsuccessful.Specifically, we will consider

Busy Waiting

Petersen’s Solution

Hardware Instruction Assistance

The Priority Inversion Problem

Sleep and Wakup

Slide 56Operating Systems© 2008 Stanley A. Wileman, Jr.

29

Mutual Exclusion with Busy Waiting

Q. How is it that a processor, executing thecode for the critical section of some process,is “redirected” to execute code for someother process?

A. It requires an interrupt or trap to divert theprocessor from the code it is executing. Thiscould be an interrupt from a timer (rememberthe process state transitions), or an interruptfrom almost any source.

Slide 57Operating Systems© 2008 Stanley A. Wileman, Jr.

Disabling Interrupts

To prevent the processor from being“yanked away,” a process could disableinterrupts just before entering a criticalsection, and re-enable interrupts afterthe critical section.

Unfortunately, this solution has someproblems…

Slide 58Operating Systems© 2008 Stanley A. Wileman, Jr.

30

Problems with Disabling Interrupts

The solution only works for systems with a singleCPU. If two CPUs sharing memory are executingtwo processes, then both processes can stillaccess the shared memory location.

It’s a dangerous approach, since an simple codingerror could result in failing to re-enable theinterrupts, which will prevent the processor fromrecognizing and handling any more interrupts!

And, of course, disabling interrupts is a privilegedinstruction, only allowed in kernel mode.

Slide 59Operating Systems© 2008 Stanley A. Wileman, Jr.

Lock Variables for Busy Waiting

The basic idea here is to use a variable (lock) thatis either 0 (resource free) or 1 (resource in use).

To enter the critical section, execute code similar tothis:

while (lock == 1) /* wait */ ;lock = 1; /* set the lock */

To exit from the critical section:lock = 0; /* release lock */

Unfortunately, there’s a race condition here! Canyou see it?

Slide 60Operating Systems© 2008 Stanley A. Wileman, Jr.

31

Lock Variable Failure – Scenario 1

Suppose we have three processes, A, B and Cusing the resource. C is in its critical section,so lock = 1. A and B are “busy waiting” forlock to become 0.

Immediately after C sets lock = 0 (on exitfrom the critical section), both A and B mightdetermine lock = 0 and then proceed to setlock = 1 and enter their critical sections.

Slide 61Operating Systems© 2008 Stanley A. Wileman, Jr.

Lock Variable Failure – Scenario 2Suppose there are just two processes, A and B,with B in its critical section and A waiting toenter.

B finishes (setting lock = 0), then A finds lock =0.

But before A has a chance to set lock = 1, Battempts to enter its critical section again, findslock = 0, and proceeds to set lock = 1.

Later, A continues to execute. Having alreadytested lock and found it 0, it proceeds to set lockto 1 and enter its critical section.

Slide 62Operating Systems© 2008 Stanley A. Wileman, Jr.

32

Busy Waiting with Strict Alternation

Instead of using a lock variable, whichleaves a window between testing thelock and setting it to 1, use a “turn”variable that indicates which process isto be allowed entry to the criticalsection.

Again assume we have two processes,A and B.

Slide 63Operating Systems© 2008 Stanley A. Wileman, Jr.

Strict Alternation

char turn = ‘A’; /* global variable *//* turn is only initialized here */

while (TRUE) {while (turn == ‘B’) /* wait */;… critical section code …turn = ‘B’;… other code …

}

This is the code for process A. Process B’s code is similar.

Slide 64Operating Systems© 2008 Stanley A. Wileman, Jr.

33

Problems with Strict Alternation

Strict alternation, although it avoids allowingmultiple processes inside their critical sectionsat the same time, doesn’t adapt well tovarying time requirements, and doesn’t meetour third solution requirement.

Busy waiting solutions also have the problemof wasting CPU time while a process iswaiting for entry to the critical section.

Slide 65Operating Systems© 2008 Stanley A. Wileman, Jr.

Dekker’s Mutual Exclusion Solution

T. Dekker, a Dutch mathematician, was the firstperson to devise a correct solution to the mutualexclusion problem without requiring strictalternation.

His solution only depends on atomic memorywrites. That is, if two processors both attemptto write to the same memory location at thesame time, the hardware guarantees that thetwo writes will be done atomically, one after theother.

Slide 66Operating Systems© 2008 Stanley A. Wileman, Jr.

34

Peterson’s Solution

G. L. Peterson, in 1981, discovered a simplersolution to the problem (Dekker’s solution israther cryptic).

His solution utilizes a turn variable (as didthe last solution), but only to resolve tiesbetween processes wanting to enter thecritical section at the same time.

It also uses an array, interested, to showwhich processes want to enter their criticalsections.

Slide 67Operating Systems© 2008 Stanley A. Wileman, Jr.

Using Peterson’s Solution

We consider only two processes, numbered 0and 1.

When a process wants to enter its criticalsection, it calls enter_region with its

process number as an argument.

When a process leaves its critical section, itcalls leave_region, again with its process

number as an argument.

Slide 68Operating Systems© 2008 Stanley A. Wileman, Jr.

35

The “enter_region” Functionvoid enter_region(int process) {

int other;other = 1 - process;interested[process] = TRUE;turn = process;while (turn == process &&

interested[other] == TRUE)/* wait */;

}

Slide 69Operating Systems© 2008 Stanley A. Wileman, Jr.

The “leave_region” Function

void leave_region (int process)

{

interested[process] = FALSE;

}

Slide 70Operating Systems© 2008 Stanley A. Wileman, Jr.

36

Hardware Assistance for the Problem

Modern processors now have hardwarefeatures to help solve the mutual exclusionproblem.

For example, the IBM S/390 has the TSinstruction, and the Intel Pentium has theXCHG instruction.

These instructions operate on two data items,one in (possibly shared) memory, and theother in a register or flag unique to aprocessor.

Slide 71Operating Systems© 2008 Stanley A. Wileman, Jr.

The S/390’s TS Instruction

The TS instruction is coded as:TS M

where M is an operand in memory.

The instruction atomically does this:1. The value of the memory operand (M) is used to

set the condition code (a set of flags inside theprocessor) to indicate if M is zero or nonzero.

2. M is set to all ones.

Slide 72Operating Systems© 2008 Stanley A. Wileman, Jr.

37

Mutual Exclusion with TSenter_region:

TS FLAG

BC 8,enter_region IF CC = 0

...return

leave_region:

XR R,R SET R = 0

ST R,FLAG

...return

Slide 73Operating Systems© 2008 Stanley A. Wileman, Jr.

The Intel XCHG Instruction

The XCHG instruction has two operands, onea processor register and the other a memoryoperand.

The instruction atomically exchanges thecontents of the operands.

The Intel manual notes “this instruction isuseful for implementing semaphores orsimilar data structures for processsynchronization.” We’ll study semaphores inthe next module.

Slide 74Operating Systems© 2008 Stanley A. Wileman, Jr.

38

Mutual Exclusion with XCHGenter_region:

MOV R,1

XCHG R,FLAG

CMP R,0

JNZ enter_region IF R = 1

...returnleave_region:

MOV FLAG,0 SET FLAG = 0

...return

Slide 75Operating Systems© 2008 Stanley A. Wileman, Jr.

Process Priorities

Operating systems frequently associatea priority with a process.

A priority is just an integer.

The system’s scheduler is designed toguarantee that the process(es) with thehighest priority are being activelyexecuting (that is, they’re in therunning state).

Slide 76Operating Systems© 2008 Stanley A. Wileman, Jr.

39

The Priority Inversion ProblemAssume we have two processes, H and L, withhigh and low priority, respectively.

The scheduler guarantees that whenever H is inthe ready state it will be run (moved to therunning state).

Assume L is running and enters its critical section,and in the meantime H becomes ready, andwants to enter its critical section.

H is moved to the running state, but no work willever get done; H will forever loop, waiting toenter its critical section.

Slide 77Operating Systems© 2008 Stanley A. Wileman, Jr.

Aging as a Solution

One solution to the priority inversionproblem is to use an aging algorithm.

In this scheme, a process that is readyto run, but doesn’t get to run becauseof its priority, is periodically given apriority “boost.”

Eventually its priority will be highenough to allow it to run.

Slide 78Operating Systems© 2008 Stanley A. Wileman, Jr.

40

Attacking the Busy Waiting Problem

Each of the solutions thus far has theunfortunate problem of requiring aprocess to loop, continually testing somecondition, until it can enter its criticalsection.

This busy waiting wastes enormousamounts of CPU time that could be betterexpended on other ready processes.

Slide 79Operating Systems© 2008 Stanley A. Wileman, Jr.

Sleep and Wakeup

Consider the use of two functions, sleepand wakeup.

Sleep causes the calling process to blockuntil it is explicitly awakened by someother process.

Wakeup causes the process identified byits parameter to be awakened, that is,moved from the blocked to the readystate.

Slide 80Operating Systems© 2008 Stanley A. Wileman, Jr.

41

Using Sleep and Wakeup

When a process discovers that it cannot enterits critical section it calls sleep, relinquishingthe processor.

When a process completes its critical section,it calls wakeup to awaken a process that issleeping.

We’ll see use of these in a proposed solutionto the producer-consumer problem.

Slide 81Operating Systems© 2008 Stanley A. Wileman, Jr.

Next…

In the next module we’ll look atcontemporary solutions to the mutualexclusion problem.

We’ll use the producer-consumerproblem as the background for ourdiscussion. This problem appears inmany places in concurrent programs,including the operating system itself.

Slide 82Operating Systems© 2008 Stanley A. Wileman, Jr.