Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Synchronization I - Slides for Operating Systems | COMP 310, Study notes of Operating Systems

Material Type: Notes; Class: Operating Systems; Subject: Computer Science; University: University of San Diego; Term: Fall 2004;

Typology: Study notes

Pre 2010

Uploaded on 08/18/2009

koofers-user-b9l
koofers-user-b9l 🇺🇸

3

(1)

10 documents

1 / 26

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
COMP 310:
Operating Systems
Lecture 4: Synchronization I
September 13, 2004
Christine Alvarado
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a

Partial preview of the text

Download Synchronization I - Slides for Operating Systems | COMP 310 and more Study notes Operating Systems in PDF only on Docsity!

COMP 310:

Operating Systems

Lecture 4: Synchronization I

September 13, 2004

Christine Alvarado

Today’s Topics

 Synchronization

 How can we ensure that all of our little processes

play nicely together?

Shared resources

 Basic problem:

 When two threads (processes) access a shared

variable, we have to control their access to that

variable to make sure they don’t clobber each

other’s work.

 We will look at many ways to ensure this

control—This is a major conceptual focus of

this class

So, what can go wrong?

 A real world example

 You and your roommates keep a grocery list on

the refrigerator door. In the morning you get up

and see that you need milk. You buy this milk on

the way home from work. What might go wrong

with your plan?

 You and your roommates are sharing

resources (and changing their state) without

any synchronization

Interleaved Schedules

 The execution of these two threads might be

interleaved:

Let’s trace the value of bal through this code

bal = get_bal(acct); bal = bal – amt; bal = get_bal(acct); bal = bal – amt; put_bal(acct, bal); put_bal(acct, bal);

Race Conditions

 A race condition occurs when two concurrent

threads access (and modify) a shared

resource without any synchronization

 (It’s a “race” to see who gets to the variable first)

 We need structured mechanisms to control

access to these shared resources

Critical Section Requirements

 Mutual exclusion

 Only one thread at a time inside critical section

 Progress

 A thread that is not in its critical section cannot

prevent another from entering

 Bounded waiting (no starvation)

 All waiting threads will eventually get to enter

 Performance

 Overhead of entering CS must be small

Solving the CS problem

 Today:

 How can we as application programmers solve

the critical section problem

 Later:

 How can OS support help us with this problem

Using locks

while (1) { acquire( lock ); critical section release( lock ); remainder section } We will look at several ways to implement this code

How can we implement locks

(focus on 2 processes)?

 Two process solution:

 Use one variable that is either set to i or j

 If it is set to i , then process i runs, if it is j , process

j runs.

Let’s try again…

 Use two different flags, indicating whether or not

each process is in its critical section

while (1) {
flag[i] = true;
while (flag[j]); // waiting
critical section
flag[i] = false;
remainder section

 Are the requirements met?

How can we fix this?

 Problem with solution #1:

 A process could only run through once

 Problem with solution #2:

 If both processes were ready at the same time, neither got
to go

 Solution:

 Two variables: one that always makes sure someone can
run, and one that indicates who wants to run
 Process A can run if:

 It’s process A’s turn  It’s process B’s turn but process B doesn’t want to run

Does this meet these

requirements?

 Mutual Exclusion

 Progress

 Bounded Waiting

Multiple Process Solution

 The bakery algorithm:
 Every process takes a number
 Processes are served in numerical order

while (1) { choosing[i] = true; number[i] = max(number[0],…, number[n-1]) + 1; for (j=0; j<n; j++) { while (choosing[j]); while ((number[j]!=0) && ((number[j]<number[i])); } critical section number[i] = 0; remainder section } What’s wrong with this solution?