Threads

1
Threads Synchronization, Conclusion

• Vivek Pai
• Nov 20, 2001

2
Mechanics

• Read Birrells paper future use
• Ill send out a link via e-mail
• Next time basic networking, IPC
• Some readings already listed, maybe more in
  e-mail
• Now wrap up threads, critical sections
• Also quiz 3 graded, working on current grades

3
Big Picture on Synchronization

• Why do we need it?
• We have multiple things running
• They perform read/write sharing of data
• Can we avoid synchronization?
• Eliminate shared data
• Perform read-only sharing
• Eliminate parallel execution

4
Synchronization Primitives

• Why so many?
• Different mechanisms for different situations
• Convenient for programmers
• Can we have fewer?
• Most can be built from first principles
• Reinvention error-prone and time-consuming
• How do you decide?
• Analysis or Idiom

5
Primitives and Purposes

• Locks
• One holder, maybe lots of waiters
• Semaphores
• Possibly lots of holders, lots of waiters
• Barriers
• Wait until everyone catches up
• Condition variables
• Waiters block, signal everyone when some
  condition occurs
• Monitors
• Expresses synchronization at a high level

6
Continuing on Synchronization

• So far, weve seen
• Spinning on lock during entire critical section
• Disabling interrupts for critical section (bad)
• Queue associated with each lock blocking
• System calls for locking possibly blocking
• Since system calls exist, is everything solved?
• Assume shared variable count
• Lock(mutex) count Unlock(mutex)

7
Cost of Protecting a Shared Variable

• Making lock system call
• Pushing parameter, sys call onto stack
• Generating trap/interrupt to enter kernel
• System call in kernel
• Jump to appropriate function in kernel
• Verify process passed in valid pointer to mutex
• Do locking operation, block process if needed
• Actually change count load/modify/store
• System call again to release mutex

8
What is Lock Contention?

• Competition for a lock
• Uncontended rarely in use by someone else
• Contended often used by someone else
• Held currently in use by someone
• Question what do these combinations do?
• Spinning on low-contention lock
• Spinning on high-contention lock
• Blocking on low-contention lock
• Blocking on high-contention lock

9
Things to Ponder

• If critical section is just count, what is
  the overhead of the synchronization
• Is there some other way of doing this?
• What if you dont know how long the critical
  section will be?

10
What If You Have the Following

• Test-and-set works at either user or kernel
• System calls for block/unblock
• Block takes some token and goes to sleep
• Unblock wakes up a waiter on token

11
User-Level Acquire/Release using Block and Unblock

• In what scenarios is this scheme appropriate?
• Where should it not be used?

12
Semaphores (Dijkstra, 1965)

• Down or P
• Atomic
• Wait for semaphore to become positive and then
  decrement by 1

• Up or V
• Atomic
• Increment semaphore by 1 wake up a waiting P if
  any

P(s) if (--s lt 0) Block(s)
V(s) if (s lt 0) Unblock(s)
13
Bounded Buffer (Consumer-Producer)

• Example
• grep vivek access.log more

Producer
Consumer
14
Bounded Buffer w/ Semaphores
mutex 1 emptyCount N fullCount
0 producer() while (1) produce an
item P(emptyCount) P(mutex) put
the item in buffer V(mutex)
V(fullCount)
consumer() while (1)
P(fullCount) P(mutex) take an item
from buffer V(mutex) V(emptyCount)
consume the item
15
Implementing General Semaphores

• Need a mutex for each semaphore
• Block and Unblock need to release mutex after
  entering their critical section

V(s) Acquire(s.mutex) if (s.value lt 0)
Unblock(s) else Release(s.mutex)
P(s) Acquire(s.mutex) if (--s.value lt 0)
Block(s) else Release(s.mutex)
16
Implement General Semaphores with Acquire/Release
P(s) Acquire(s.mutex) if (--s.value lt 0)
Release(s.mutex) Acquire(s.delay)
else Release(s.mutex)
V(s) Acquire(s.mutex) if (s.value lt 0)
Release(s.delay) Release(s.mutex)

• Kotulski (1988)
• Two processes call P(s) (when s.value is 0) and
  preempted after Release(s.mutex)
• Two other processes call V(s)

17
Hemmendingers Solution (1988)
P(s) Acquire(s.mutex) if (--s.value lt 0)
Release(s.mutex) Acquire(s.delay)
Release(s.mutex)
V(s) Acquire(s.mutex) if (s.value lt 0)
Release(s.delay) else
Release(s.mutex)

• The idea is not to release s.mutex and turn it
  over individually to the waiting process
• P and V are executing in lockstep

18
Kearnss Solution (1988)
P(s) Acquire(s.mutex) if (--s.value lt 0)
Release(s.mutex) Acquire(s.delay)
Acquire(s.mutex) if (--s.wakecount gt 0)
Release(s.delay) Release(s.mutex)
V(s) Acquire(s.mutex) if (s.value lt 0)
s.wakecount Release(s.delay)
Release(s.mutex)
Two Release( s.delay) calls are also possible
19
Hemmendingers Correction (1989)
P(s) Acquire(s.mutex) if (--s.value lt 0)
Release(s.mutex) Acquire(s.delay)
Acquire(s.mutex) if (--s.wakecount gt 0)
Release(s.delay) Release(s.mutex)
V(s) Acquire(s.mutex) if (s.value lt 0)
s.wakecount if (s.wakecount 1)
Release(s.delay) Release(s.mutex)
Correct but a complex solution
20
Hsiehs Solution (1989)
P(s) Acquire(s.delay) Acquire(s.mutex)
if (--s.value gt 0) Release(s.delay)
Release(s.mutex)
V(s) Acquire(s.mutex) if (s.value 1)
Release(s.delay) Release(s.mutex)

• Use Acquire(s.delay) to block processes
• Correct but still a constrained implementation

21
Definition Time

• Whats a semaphore?
• OED says signaling mechanism using flags,
  especially used for rail and sea
• Whats a monitor? Is it
• A device to watch a signal without disrupting it
• A person who watches, enforces, etc
• A programming-language construct for exclusion
• A giant lizard

22
Answer All of the Above

• Up to 6.5 feet long
• Thought to alert for the presence of crocodiles

23
Natural Habitat of the Monitor

• The Mesa system
• Xerox PARC (Palo Alto Research Center)
• Cool place
• Lots of neat stuff developed there
• Digital SRC
• Exodus of people from PARC
• Language, parallelism focus

24
Motivation
Enqueue(q, item) Acquire(mutex) put item
into q Release(mutex)
Dequeue(q) Acquire(mutex) take an item
from q Release(mutex) return item

• What we want
• Dequeue(q) blocks until q is not empty
• Semaphores are difficult to use orders are
  important

25
Think About Critical Sections

• What are they?
• Pieces of code in the parallel environment
• What makes code a critical section?
• Correctness constraints, ultimately
• But really, what makes code a critical section?
• Is there some way to take advantage of this?
• If so, when?

26
Answer Push It To The Compiler

• Easier on programmer
• Compiler gets it right once
• Programmer gets it wrong often
• Information available at compile-time
• Small amount of programmer annotation

27
Monitor Hides Mutual Exclusion

• Procedures are mutually exclusive

Shared data
Queue of waiting processes trying to enter the
monitor
...
procedures
28
Condition Variables in A Monitor
Queues associated with x, y conditions

• Wait( condition )
• Block on condition
• Signal( condition )
• Wakeup a blocked process on condition
• Conditions are not sticky

x
y
Shared data
...
Entry queue
operations
29
Producer-Consumer with Monitors
monitor ProdCons condition full, empty
procedure Enter begin if (the queue is
full) wait(full) put item into
buffer if (only one item)
signal(empty) end procedure Remove
begin if (buffer is empty)
wait(empty) remove an item if (buffer
was full) signal(full) end
procedure Producer begin while true do begin
produce an item ProdCons.Enter()
end end procedure Consumer begin while true
do begin ProdCons.Remove() consume an
item end end
30
Wow, This Looks Like Cake!

• Well, the language/compiler has to support it
• One problem what happens on wakeup?
• Only one thing can be inside monitor
• Wakeup implies signaller, waiter in monitor

31
Options of the Signaler

• Exit the monitor (Hansen)
• Relinquishes control to the awaken process and
  suspend the current one (Hoare)
• Complex if the signaler has other work to to
• To make sure there is no work to do is difficult
  because the signal implementation is not aware
  how it is used
• It is easy to prove things
• Continues its execution (Mesa)
• Easy to implement
• But, the condition may not be true when the
  awaken process actually gets a chance to run

32
Mesa Style Monitor(Birrells Paper)

• Acquire and Release
• Wait( lock, condition )
• Atomically unlock the mutex and enqueued on the
  condition variable (block the thread)
• Re-lock the lock when it is awaken
• Signal( condition )
• Noop if there is no thread blocked on the
  condition variable
• Wake up at least one if there are threads blocked
• Broadcast( condition )
• Wake up all

33
Example

• Add an item to the queue
• Acquire( mutex )
• add an item to the queue
• Signal( nonEmptyCond )
• Release( mutex )
• Remove an item from a queue
• Acquire( mutex )
• while ( queue is empty )
• Wait( mutex, nonEmptyCond )
• remove an item
• Release( mutex )
• Question Can while be replaced by if

34
Mesa-Style vs. Hoare-Style Monitor

• Mesa-style
• Signaller keeps lock and CPU
• Waiter simply put on ready queue, with no special
  priority
• Hoare-style
• Signaller gives up lock and waiter runs
  immediately
• Waiter gives lock and CPU back to signaller when
  it exits critical section or if it waits again

35
Condition Variables Primitives

• Wait( mutex, cond )
• Enter the critical section (min busy wait)
• Release mutex
• Put my PCB to conds queue
• Call scheduler
• Exit the critical section
• Acquire mutex

• Signal( cond )
• Enter the critical section (min busy wait)
• Wake up one PCB in conds queue
• Exit the critical section

36
Are Monitors Alive Today?

• Actual monitors were fairly dead
• Java resurrected them
• What killed the monitor?
• Man encroached on their environment just
  kidding
• Language support a real dead weight
• C kills everything not-C
• But they still exist, sort of
• Condition variables, etc., used heavily