Class 7
CS 170
26 October 2020

On the board
------------

1. Concurrency/synchronization so far
2. Condition variables
3. Monitors

---------------------------------------------------------------------------

1. Concurrency/synchronization so far
    
    --threads: why do we have them?

        --oftentimes a natural way to structure a computing task 

    --once we have threads, we have to worry about *concurrent access to
    shared memory*: multiple execution contexts modifying the same
    memory at the same time

        --because there are multiple CPUs (with threads running on those
        CPUs)

        --or because the instructions from different threads can be
        interleaved on one CPU, owing to scheduling
        
    --this state of affairs has to be controlled: *synchronization*.

        --accesses of shared variables (for example, "count" in
        the bounded buffer example) are said to be in a _critical section_

        --Critical sections are protected from concurrent execution

    --classic synchronization primitive: the mutex.

        --> we have told you about the *interface* to mutexes (how they
        are used). we haven't said much about their *implementation*; you
        can refer the textbook to learn more about the implementation

    --you may at this point have an intuition for mutexes (they
    guarantee mutual exclusion, which sounds good), but what are they
    really accomplishing?

        --*atomicity* is required if you want to reason about code
        without contorting your brain to reason about all possible
        interleavings

        --atomicity requires mutual exclusion aka a solution to critical
        sections

        --mutexes provide that solution

        --once you have mutexes, don't have to worry about arbitrary
        interleavings. critical sections are interleaved, but those are
        much easier to reason about than individual operations.

        --why? because of _invariants_.

            examples of invariants:

            "list structure has integrity"

            "'count' reflects the number of entries in the buffer"

        the meaning of lock.acquire() is that if and only if you get
        past that line, it's safe to violate the invariants.

        the meaning of lock.release() is that right _before_ that line,
        any invariants need to be restored.

        an example:

            invariant: "list structure has integrity"

            so protect the list with a mutex

            only after acquire() is it safe to manipulate the list

2. Condition variables

    A. Motivation

        --producer/consumer queue 

	    --very common paradigm. also called "bounded buffer":

	        --producer puts things into a shared buffer
	        --consumer takes them out
	        --producer must wait if buffer is full; consumer must
	          wait if buffer is empty
	        --shows up everywhere
		    --Soda machine: producer is delivery person, consumer
		        is soda drinkers, shared buffer is the machine
		    --OS implementation of pipe()
		    --DMA buffers
                
	--producer/consumer queue using mutexes

	    --what's the problem with that?

	    --answer: a form of *busy waiting* 

	--It is convenient to break synchronization into two types:

	    --*mutual exclusion*: allow only one thread to access a given
	    set of shared state at a time

	    --*scheduling constraints*: wait for some other thread to do
	    something (finish a job, produce work, consume work, accept
	    a connection, get bytes off the disk, etc.)


    B. Usage

	--API

	    --void cond_init (Cond *, ...); 
		--Initialize

	    --void cond_wait(Cond *c, Mutex* m);
		--Atomically unlock m and sleep until c signaled 
		--Then re-acquire m and resume executing 

	    --void cond_signal(Cond* c);

		--Wake one thread waiting on c

		[in some pthreads implementations, the analogous
		call wakes *at least* one thread waiting on c. Check the
		the documentation (or source code) to be sure of the
		semantics. But, actually, your implementation shouldn't
		change since you need to be prepared to be "woken" at
		any time, not just when another thread calls signal().
		More on this below.]

	    --void cond_broadcast(Cond* c);

		--Wake all threads waiting on c

    C. Important points

        (1) We MUST use "while", not "if". Why?

	    --Because we can get an interleaving like this:

	        --The signal() puts the waiting thread on the ready list
	        but doesn't run it

	        --That now-ready thread is ready to acquire() the mutex
	        (inside cond_wait()).

	        --But a *different* thread (a third thread: not the
	        signaler, not the now-ready thread) could acquire() the
	        mutex, work in the critical section, and now invalidates
	        whatever condition was being checked

	        --Our now-ready thread eventually acquire()s the
	        mutex...

	        --...with no guarantees that the condition it was
	        waiting for is still true
	        
	    --Solution is to use "while" when waiting on a condition
	    variable

	    --DO NOT VIOLATE THIS RULE; doing so will (almost always)
	    lead to incorrect code

            --NOTE: NOTE: NOTE: There are two ways to understand
            while-versus-if:
            (a) It's the 'while' condition that actually guards the program.
            (b) There's simply no guarantee when the thread proceeds that
            the condition hods. 
        
        (2) cond_wait releases the mutexes and goes into the waiting
        state in one function call

            --QUESTION: Why?
            --That is, why does cond_wait need to both release the
            mutex and sleep? Why not:
                
                while (count == BUFFER_SIZE) {
                    release(&mutex);
                    cond_wait(&nonfull);
                    acquire(&mutex);
                }

	    --Answer: can get stuck waiting.

	        Producer: while (count == BUFFER_SIZE)
	        Producer: release()
	        Consumer: acquire()
	        Consumer: .....
	        Consumer: cond_signal(&nonfull)
	        Producer: cond_wait(&nonfull)

	    --Producer will never hear the signal!


3. Monitors

    Monitors = mutex + condition variables

    --High-level idea: an object (as in object-oriented systems)
	
	--in which methods do not execute concurrently; and

	--that has one or more condition variables

    --More detail
    
	--Every method call starts with acquire(&mutex), and ends with
	release(&mutex)

	--Technically, these acquire()/release() are invisible to the
	programmer because it is the programming language (i.e., the
	compiler+run-time) that is implementing the monitor

	    --So, technically, a monitor is a programming language
	    concept

	    --But technical definition isn't hugely useful because no
	    programming languages in widespread usage have true monitors

	    --Java has something close: a class in which every method is
	    set by the programmer to be "synchronized" (i.e., implicitly
	    protected by a mutex)

		--Not exactly a monitor because there's nothing forcing
		every method to be synchronized

	    --And we can *use* mutexes and condition variables to
	    implement our own manual versions of monitors, though we
	    have to be careful
	
	--Given the above, we are going to use the term "monitor" more
	loosely to refer to both the technical definition and also a
	"manually constructed" monitor, wherein:
	
	    --all method calls are protected by a mutex (that is, the
	    programmer inserts those acquire()/release() on entry and
	    exit from every procedure *inside* the object)
	    
	    --synchronization happens with condition variables whose
	    associated mutex is the mutex that protects the method calls

	--In other words, we will use the term "monitor" to refer to the
	programming conventions that you should follow when building
	multithreaded applications

	    --you must follow these conventions on lab 3

    --Example: see video lecture for producer/consumer as a monitor

    --RULE:
    
	--acquire/release at beginning/end of methods

    --RULE:

	--hold lock when doing condition variable operations

	--Some people
	    [for example, Andrew Birrell in this paper:
            http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-35.pdf ]
	will say: "for experts only, no need to
	hold the lock when signaling". IGNORE THIS. Putting the signal
	outside the lock is only a small performance optimization, and
	it is likely to lead you to write incorrect code.
	
	--in Lab 3, you must hold the associated mutex
	when doing a condition variable operation

    --Different styles of monitors:

	--Hoare-style: signal() immediately wakes the waiter

	--Hansen-style and what we will use:
	signal() eventually wakes the waiter. Not an immediate transfer

    --Can we replace SIGNAL with BROADCAST, given our monitor semantics?
     (Answer: yes, always.) Why?

	--while() condition tests the needed invariant. program
	doesn't progress pass while() unless the needed invariant is
	true.

	--result: spurious wake-ups are acceptable....

	--...which implies you can always wakeup a thread at any
	moment with no loss of correctness....

	--....which implies you can replace SIGNAL with BROADCAST
	[though it may hurt performance to have a bunch of
	needlessly awake threads contending for a mutex that they
	will then acquire() and release().]

    --RULE:

	--a thread that is in wait() must be prepared to be restarted at
	any time, not just when another thread calls "signal()".

	--why? because the implementor of the threads and condition
	variables package *assumes* that the user of the threads package
	is doing while(){wait()}.

    --Can we replace BROADCAST with SIGNAL?

	--Answer: not always. 

	--Example:
	    --memory allocator
	    --threads allocate and free memory in variable-sized chunks
	    --if no memory free, wait on a condition variable
	    --now posit:
		--two threads waiting to allocate chunks of memory
		--no memory free at all
		--then, a third thread frees 10,000 bytes
	    --SIGNAL alone does the wrong thing: we need to awaken both
	    threads