Download Threads and Concurrency Projects - Operating System | EECS 482 and more Study Guides, Projects, Research Electrical and Electronics Engineering in PDF only on Docsity!
EECS 482
1
Thr
eads and concurr
ency
Motivation
- operating systems getting really complex• multiple users, programs, I/O devices, etc.• how to manage this complexity?
Decompose or separate hard problem into several simpler onesPrograms decompose into several rows (horizontal layers)
main()
{
getInput();computeResult();printOutput(); } getInput() {
cout();cin(); } computeResult() {
sqrt();pow(); } printOutput() {
cout(); }
Processes decompose mix of activities running on a processor
into several parallel tasks (columns)• each job can work independently of the others
Remember, for any area of OS, ask:
- What’s the hardware interface?• What’s the application interface?
main
getInput
cout
job 1
job 2
job 3
EECS 482
2
What’
s in a pr
ocess?
Definition of a process
- (informal) a program in execution. A running piece of
code along with all the things the program can read/writenote that process != program
threads
in their own
address space
Play analogyThread
- sequence of executing instructions from a program (i.e.
the running computation)
- active• play analogy: the acting being done by an actor in the
play
Address space
- all the data the process uses as it runs• passive (acted upon by the thread)• play analogy: all the objects on the stage in a play
T
ypes of data in the addr
ess space
EECS 482
4
Can thr
eads truly be independent?
Possible to have multiple threads on a computer system that
don’t cooperate or interact at all?• what about multiple programs that are related, e.g. mail
program reads a PDF attachment and starts acroreadprocess to display the attachment?
- what about multiple independent programs on a single
computer, e.g. running Quake and 482 project at thesame time?
Two possible sources of sharingCorrect example of non-interacting threads
W
eb ser
v
er example
But if threads are cooperating, is it still a helpful abstraction to
think of multiple threads? Or is it simpler to think of a sin-gle thread doing multiple things?
How to build a web server that receives multiple, simultaneous
requests, and that needs to read web pages from disk to sat-isfy each request?
Handle one request at a time
- easy to program, but slow. Can’t overlap disk requests
with computation or with network receive
EECS 482
5
Finite-state machine with asynchronous I/Os
- need to keep track of multiple outstanding requests
request 1 arrivesweb
server receives request 1
web
server starts disk I/O 1a to satisfy request 1
request 2 arrivesweb
server receives request 2
web
server starts disk I/O 2a to satisfy request 2
request 3 arrivesdisk
I/O 1a finishes
- At each point, web server must remember what requests
have arrived and are being serviced, what disk I/Os areoutstanding and which requests they belong to, and whatdisk I/Os still need to be done to satisfy each request.
Multiple cooperating threads
- each thread handles one request• each thread can issue a
blocking
disk I/O, wait for I/O to
finish, then continue with next part of its request
- even though thread blocks, other threads can make
progress (and new threads can start to handle newrequests)
- where is the state of each request stored?
Benefits and uses of thr
eads
Thread system in operating system manages the sharing of the
single CPU among several threads (e.g. allowing onethread to issue a blocking I/O and still allow other threadsto make progress). Applications (or higher-level parts ofthe OS) get a simpler programming model)
Typical domains that use multiple threads
- program uses some slow resource, so it pays to have mul-
tiple things happening at once.
- physical control (e.g. airplane controller)
slow component:
- window system (1 thread per window)
slow component:
slow component
- parallel programming (for using multiple CPUs)
slow component:
EECS 482
7
Arithmetic example
- (initially y=10)• thread A: x = y + 1;• thread B: y = y * 2;• possible results?
Atomic operations
Example
- thread A: x=1• thread B: x=2• possible results?• is 3 a possible output?
Before we can reason
at all
about parallel processes, we must
know that some operation is
atomic
EECS 482
8
Atomic: indivisible. Either happens in its entirety without
interruption, or has yet to happen at all.• no events from other threads can happen in between the
start and end of an atomic event
In above example, if assignment to x is atomic, then only pos-
sible results are 1 and 2.
In print example above, what are the possible outputs if each
print statement is atomic?
Print example above assumed printing a single character was
atomic. What if printing a single character was
not
atomic?
On most machines, memory load and store are atomicBut many instructions are
not
atomic, e.g. double-precision
floating point on a 32-bit machine (two separate memoryoperations)
If you don’t have any atomic operations, you can’t make one.
Fortunately, the hardware folks give us atomic operations,and we can build up higher-level atomic primitives fromthere
Another example: thread A
thread
B
i=
i=
while (i < 10) {
while
(i
-10)
{
i++
i--
}
}
print “A wins”
print
“B
wins”
Who will win?Is it guaranteed that someone will win?What if threads run at exactly the same speed and start close
together? Is it guaranteed that it goes on forever?• What if i++ and i-- are not atomic?• Should you worry about this actually happening?
EECS 482
10
T
oo much milk
Problem definition
- Janet and Peter want to keep refrigerator stocked with at
most one milk jug
- if either sees fridge empty, she/he goes to buy milk• correctness properties: someone will buy milk if needed,
but never more than one person buys milk
Solution #0 (no synchronization)
Peter:
Janet:
if
(noMilk) {
if (noMilk) {
buy
milk
buy milk
}
}
Peter
Janet
3:
look
in fridge (no
milk)
3:
leave
for Kroger
3:
arrive
at Kroger
look in fridge
(no milk)
3:
buy
milk
leave for Kroger
3:
arrive
home, put
arrive at Kroger
in
fridge
3:
buy milk
3:
arrive home, put
milk in fridge.Too much milk!
First type of synchr
onization:
mutual exclusion
Mutual exclusion
- ensure that only 1 thread is doing a certain thing at one
time (others are excluded). E.g. only 1 person goesshopping at a time.
Critical section
- a section of code that needs to run atomically with
respect to selected other pieces of code.
- if code A and code B are critical sections with respect to
each other, then multiple threads should not be able tointerleave events from A and B.
- critical sections must be atomic with respect to each other
because they share data (or other resources, e.g. screen,refrigerator)
- e.g. in too much milk solution #0, critical section is “if
(noMilk), buy milk. Peter and Janet’s critical sectionsmust be atomic with respect to each other, i.e. eventsfrom these critical sections must not be interleaved.
EECS 482
11
Peter M. Chen
T
oo much milk (solution #1)
Assume that the only atomic operations are load and storeIdea: leave note that you’re going to check on the milk status,
so other person doesn’t also buy Peter:
Janet:
if
(noNote) {
if (noNote) {
leave
note
leave note
if
(noMilk) {
if (noMilk) {
buy
milk
buy milk
}
}
remove note
remove note
}
}
Does this work? If not, when could it fail?Is solution #1 better than solution #0?
T
oo much milk (solution #2)
Idea: change the order of “leave note” and “check note”. This
requires labeled notes (otherwise you’ll see your own noteand think it was the other person’s note)
Peter:
Janet:
leave notePeter
leave
noteJanet
if (no noteJanet)
{
if (no notePeter) {
if (noMilk)
{
if
(noMilk)
{
buy milk
buy
milk
}
}
}
}
remove notePeter
remove
noteJanet
Does this work? If not, when could it fail?
EECS 482
13
Higher
-le
v
el synchr
onization
Solution: raise the level of abstraction to make life easier for
programmer
Locks (mutexes)
A lock prevents another thread from entering a critical section.
e.g. before shopping, leave a note on the fridge, so thatboth Peter and Janet don’t go shopping
Two operations
•^
lock()
: wait until lock is free, then acquire it^ do {
if (lock
is
free)
{
acquire
lock
break
} } while
(1)
•^
unlock()
: release lock
Why was the “note” in Too Much Milk solutions #1 and #2 not
a good lock?
Four elements of locking
- lock is initialized to be free• acquire lock before entering critical section• release lock when exiting critical section• wait to acquire lock if another thread already holds it
All synchronization involves waitingThread can be
running
, or
blocked
(waiting for something)
concurrent programshigh-level synchronization operations provided bysoftware (e.g. locks, semaphores, monitors) low-level atomic operations provided by hardware(e.g. load/store, interrupt enable/disable, test&set)
EECS 482
14
Peter M. Chen
Locks make “Too much milk” really easy to solve!
Peter:
Janet:
lock()
lock()
if
(noMilk) {
if (noMilk) {
buy
milk
buy milk
}
}
unlock()
unlock()
But this prevents Janet from doing stuff while Peter is shop-
ping. I.e. critical section includes the shopping time.
How to minimize the critical section?
Thr
ead-safe queue with locks
enqueue() {
/* find tail
of
queue
*/
for (ptr=head;
ptr->next
!=
NULL;
ptr =
ptr->next);
/* add new element
to
tail
of
queue
*/
ptr->next = new_element;new_element->next
=
NULL;
} dequeue() {
/* if something
on
queue,
then
remove
it
*/
if (head->next
!=
NULL)
{
element =
head->next;
head->next
=
head->next->next;
} return(element);
} What bad things can happen if two threads manipulate queue
at same time?
EECS 482
16
What if you wanted to have dequeue()
wait
if the queue is
empty?
EECS 482
17
T
w
o types of synchr
onization
Mutual exclusion
- ensure that only 1 thread (or more generally, less than N
threads) is in critical section
Ordering constraints
- used when thread should wait for some event (not just
another thread leaving a critical section)
- used to enforce before-after relationships• e.g. dequeuer wants to wait for enqueuer to add some-
thing to the queue
Monitors
Note that this differs from Tanenbaum’s treatment in Section
Monitors use separate mechanisms for the two types of syn-
chronization• use
locks
for mutual exclusion
condition variables
for ordering constraints
A monitor = a lock + the condition variables associated with
that lock
EECS 482
19
Mesa vs. Hoar
e monitors
So far have described Mesa monitors
- when waiter is woken, it must contend for the lock with
other threads
- hence must re-check condition
What would be required to ensure that the condition is met
when the waiter returns from wait and starts runningagain?
Hoare monitors give special priority to the woken-up waiter
- signalling thread gives up lock (hence signaller must re-
establish invariant before calling signal())
- woken-up waiter acquires lock• signalling thread re-acquires lock after waiter unlocks
We’ll stick with Mesa monitors (as do most operating systems)
T
ips f
or pr
ogramming with monitors
List the shared data needed to solve the problemDecide which locks (and how many) will protect which data
- more locks (protecting finer-grained data) allows differ-
ent data to be accessed simultaneously, but is more com-plicated
- one lock usually enough in this class
Put lock...unlock calls around the code that uses shared dataList before-after conditions
- one condition variable per condition• condition variable’s lock should be the lock that protects
the shared data that is used to evaluate the condition
Call wait() when thread needs to wait for a condition to be
true; use a while loop to re-check condition after waitreturns
Call signal when a condition changes that another thread might
be interested in
Make sure invariant is established whenever lock is not held
(i.e. before you call unlock, and before you call wait)
EECS 482
20
Pr
oducer
-consumer (bounded b
uffer)
Problem: producer puts things into a shared buffer, consumer
takes them out. Need synchronization for coordinatingproducer and consumer.• e.g. Unix pipeline (gcc calls cpp | cc1 | cc2 | as)• buffer between producer and consumer allows them to
operate somewhat independently. Otherwise must oper-ate in lockstep (producer puts one thing in buffer, thenconsumer takes it out, then producer adds another, thenconsumer takes it out, etc.)
E.g. coke machine
- delivery person (producer) fills machine with cokes• students (consumer) buy cokes and drink them• coke machine has finite space
Pr
oducer
-consumer using monitors
Variables
- shared data for the coke machine (assume coke machine
can hold “max” cokes)
- numCokes (number of cokes in machine)
One lock (cokeLock) to protect this shared data
- fewer locks make the programming simpler, but allow
less concurrency
Ordering constraints
- consumer must wait for producer to fill buffer if all buff-
ers are empty (ordering constraint)
- producer must wait for consumer to empty buffer if buff-
ers is completely full (ordering constraint)
consumer
producer
