CS444CS544 Operating Systems

1
CS444/CS544Operating Systems

• Synchronization
• 3/21/2006
• Prof. Searleman
• jets_at_clarkson.edu

2
Outline

• Synchronization methods
• Monitors Semaphore solutions
• Producer/Consumer (bounded buffer)
• Readers/Writers
• Dining Philosophers
• NOTE
• HW6 and Lab2 due this week (by Friday)
• HW7 posted, due 3/28
• Read Chapter 8
• Class on Thursday is HERE (Snell, NOT lab)

3
Announcements IBM Workshopon IMS, Saturday,
9-4, ITL

• Want a Career in IMS? What is IMS you ask?Well
  if you've ever used an ATM then you've probably
  used IMS. If you've done Web banking, you've
  probably used IMS. If you've called FEDEX to
  track your package, guess what? FEDEX uses IMS.
  Major fortune 500 companies use it.IMS
  (Information Management System) is IBM's premiere
  Hierarchical Database system that runs on a
  mainframe system (those large corporate
  computers).Visit the IMS home page at
  http//www-306.ibm.com/software/data/ims/

4
Announcements IBM Workshopon IMS, Saturday,
9-4, ITL

• The first half of the seminar will describe the
  following- Architecture of IMS
• - The different IMS database types- Database
  recovery facilities.- IMS Transaction
  management.- Some of the special facilities
  MSC, RSR XRF.
• The second half of the seminar contains a live
  demo operating and using an IMS system followed
  by discussions of the various Job opportunities
  in IMS System programming, Database
  Administration, Application Programming, Testing
  and Technical support
• Lunch and refreshments will be provided!!!
• Please see Prof. Searleman or Prof. Matthews to
  sign up

5
Classical Synchronization Problems

• Bounded-Buffer Problem (also called
  Producer-Consumer)
• one-way communication with limited resources
• Dining-Philosophers Problem
• shared resources
• Readers and Writers Problem shared database

6
Setting up a synchronization problem

• How to use semaphores
• How to use a monitor
• How to use condition variables
• Shown in class

7
Bounded BufferProducer/Consumer

• Finite size buffer (array) in memory shared by
  multiple processes/threads
• Producer threads produce an item and place it
  in the buffer
• Consumer threads remove an item from the buffer
  and consume it
• Why do we need synchronization?
• Shared data the buffer state
• Which parts of buffer are free? Which filled?
• What can go wrong?
• Producer doesnt stop when no free spaces
  Consumer tries to consume an empty space
  Consumer tries to consume a space that is only
  half-filled by the producer Two producers try to
  produce into same space Two consumers try to
  consume the same space,

8

• Producer thread
• Reason(s) to wait?
• How to implement?
• Consumer thread
• Reason(s) to wait?
• How to implement?
• CONCEPT Producers produce items to be stored in
  the buffer. Consumers remove and consume items
  which have been stored. Mutual exclusion must be
  enforced on the buffer itself. Moreover,
  producers can store only when there is an empty
  slot, and consumers can remove only when there is
  a full slot.

9
Monitor Solution to Producer/Consumer

• The buffer and its control variables are
  encapsulated by a monitor. The monitor provides
  procedures to put an item in the buffer and to
  take an item out of the buffer. The monitor
  includes two condition variables slot_free
  represents the condition that there is space for
  an item, and item_present represents the
  condition that at least one item is present in
  the buffer.
• In this example, the buffer is implemented as an
  array of size MAX treated as a circular (ring)
  buffer. Variables in and out give the index of
  the next position for putting in and taking out
  (if any). Variable count gives the number of
  items in the buffer.

10
Structure of a Monitor

• monitor BB
• // shared variables
• condition slot_free, item_present
• anytype bufferMAX
• int in, out, count
• // monitor procedures
• void put_in_buffer(anytype item)
• anytype get_from_buffer(void)
• // initialization code for shared variables
• in 0 out 0 count 0
• // end monitor BB

11
Producer Consumer threads

• PRODUCER
• repeat
• / produce an item /
• item produce()
• / put it in the buffer /
• BB.put_in_buffer(item)
• until done

• CONSUMER
• repeat
• / get item from the buffer /
• item BB. get_from_buffer()
• / consume it /
• consume(item)
• until done

12

• void put_in_buffer(anytype item)
• / if no space is available, wait for one /
• if (count gt MAX) slot_free.wait()
• / store the item /
• bufferin item in in 1 mod n
• count count 1
• / signal that the item is present /
• item_present.signal()
• anytype get_from_buffer(void)
• anytype item
• / if no items are present, wait for one /
• if (count lt 0) item_present.wait()
• / get the next item /
• item bufferout out out 1 mod n
• count count - 1
• / announce that a space is free /
• slot_free.signal()

13
Semaphore Solution to Bounded-Buffer

• semaphore_t mutex
• semaphore_t full
• semaphore_t empty
• container_t
• BOOL free TRUE
• item_t item
• container_t bufferFIXED_SIZE
• void initBoundedBuffer
• mutex.value 1
• full.value 0
• empty.value FIXED_SIZE

14
Semaphore Solution to Bounded-Buffer
void producer () container_t which wait(empt
y) wait(mutex) which findFreeBuffer() wh
ich-gtfree FALSE which-gtitem
produceItem() signal(mutex) signal(full)
void consumer () container_t which wait(full
) wait(mutex) which findFullBuffer() con
sumeItem(which-gtitem) which-gtfree
TRUE signal(mutex) signal(empty)

• Can we do better? Lock held while
  produce/consume? Exercise

15
Readers/writers

• Shared data area being accessed by multiple
  processes/threads
• Reader threads look but dont touch
• We can allow multiple readers at a time. Why?
• Writer threads touch too.
• If a writer present, no other writers and no
  readers. Why?
• Is Producer/Consumer a subset of this?
• Producers and consumers are both writers
• Producer writer type A Consumer writer type
  B and there are no readers
• What might be a reader? Report current num full.

16
Semaphore Solution to Readers/ Writers (Reader
Preference)
void reader () wait(mutex) numReaders if
(numReaders 1) wait(okToWrite) //not ok to
write signal(mutex) do reading (could pass
in pointer to read function) wait(mutex) numRe
aders-- if (numReaders 0)
signal(okToWrite) //ok to write again signal
(mutex)

• semaphore_t mutex
• semaphore_t okToWrite
• int numReaders
• void init
• mutex.value 1
• okToWrite.value 1
• numReaders 0
• void writer ()
• wait(okToWrite)
• do writing (could pass
• in pointer to write function)
• signal(okToWrite)

Can we do better? Fairness to writers?
17
Monitor Solution toReaders/Writers

• reader thread
• reason(s) to wait?
• how to implement?
• writer thread
• reason(s) to wait?
• how to implement?
• fairness
• dont want to starve either readers or writers

18
Reader/Writer Monitor

• monitor RW
• // shared variables
• condition OKtoread, OKtowrite
• int readercount, waitingWriters, waitingReaders
• boolean busy
• // 4 monitor procedures
• void startRead() void endRead()
• void startWrite() void endWrite()
• // initialization code for shared variables
• readercount 0 busy false
• waitingWriters waitingReaders 0
• // end monitor RW

19
Reader Writer threads

• READER
• repeat
• RW.startRead()
• / read database /
• RW.endRead()
• until done

• WRITER
• repeat
• RW.startWrite()
• / update database /
• RW.endWrite()
• until done

20

• // Monitor procedures for readers
• void startRead()
• if ( busy (waitingWriters gt 0) )
• waitingReader
• OKtoRead.wait()
• waitingReaders--
• readercount readercount 1
• OKtoRead.signal()
• void endRead()
• readercount readercount - 1
• if (readercount 0)
• OKtoWrite.signal()

21

• // Monitor procedures for writers
• void startWrite()
• if ( (readercount ! 0) busy )
• waitingWriters
• OKtoWrite.wait()
• waitingWriters--
• busy true
• void endWrite()
• busy false
• if (waitingReaders gt 0)
• OKtoRead.signal()
• else
• OKtoWrite.signal()

22
Semaphore Solution to Readers/ Writers (Fair)

• semaphore_t readCountMutex, incoming, next
• int numReaders
• BOOL writeInProgress,readInProgress
• void init
• readCountMutex.value 1
• incoming.value 1
• next.value 1
• numReaders 0
• writeInProgress FALSE
• readInProgress FALSE

23
void reader () wait(incoming) if
(!readInProgress) wait(next)
wait(readCountMutex) numReaders
readInProgress TRUE signal(readCountMutex)
// if next thread on incoming // is writer,
will block on next signal(incoming) // do
reading wait(readCountMutex) numReaders--
if (numReaders 0) readInProgress
FALSE if (next.value 0) signal
(next) signal(readCountMutex)

• void writer()
• wait(incoming)
• wait(next)
• writeInProgress TRUE
• // let someone else move
• // on, and wait on next
• signal(incoming)
• // do writing
• writeInProgress FALSE
• if (next.value 0)
• signal(next)

24
Converting a monitor solution to a semaphore
solution

• Basic concept
• Each condition c simulated with
• semaphore cSem 0
• For mutual exclusion, introduce a new semaphore
  semaphore mutex 1
• A wait on a condition variable c c.wait()
  becomes
• signal(mutex) // release exclusion
• wait(cSem) // block
• wait(mutex) // regain exclusion before
  accessing
• // shared variables
• What about a signal on a condition variable?

25
Dining Philosophers

• monitor DP
• enum Statethinking, hungry, eating
• State moodsNUM_PHIL
• condition selfNUM_PHIL
• void pickup(int i)
• void putdown(int i)
• void test(int i)
• void init()
• for (int i 0 i lt NUM_PHIL i)
• statei thinking
• // end DP

26
Dining Philosophers

• void pickup(int i)
• statei hungry
• test(i) // check if OK to eat
• if (statei ! eating)
• selfi.wait()
• void putdown(int i)
• statei thinking
• // test left and right neighbors
• test((i (NUM_PHIL-1 )) NUM_PHIL)
• test((i1) NUM_PHIL)

27
Dining Philosophers

• void test(int i)
• if ((state(i NUM_PHIL-1) NUM_PHIL !
  eating)
• (statei hungry)
• (state(i 1) NUM_PHILOSOPHERS ! eating))
  
• statei eating
• selfi.signal()

28
Philosopher Threads

• void philosophersLife(int i)
• while(1)
• think()
• DP.pickupChopticks()
• eat()
• DP.putdownChopsicks()

29
Remember

• Game is obtaining highest possible degree of
  concurrency and greatest ease of programming
• Tension
• Simple high granularity locks easy to program
• Simple high granularity locks often means low
  concurrency
• Getting more concurrency means
• Finer granularity locks, more locks
• More complicated rules for concurrent access

30
Other Classic Synchronization Problems

• Sleeping Barber
• Traffic lights for two lane road through a one
  lane tunnel