Class 5
CS 170
19 October 2020

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

1. Last time
2. Threads
3. Intro to concurrency

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

1. Last time

    shell

    fork()/exec() separation


    capabilities vs. mechanism

	* Why are pipelines interesting?

	    --what if ls had to be able to paginate its input?

	    --with pipes, program doesn't have to get recompiled

	    --program doesn't have to take file/device/whatever as input

	    --prior to Unix, there was little to no composability. programs
	    had to do everything or use temporary files awkwardly

         * What makes a good abstraction?

            --simple but powerful

            --examples we've seen:

                --stdin (0), stdout (1), stderr (2) [nice by themselves, but
                when combined with the mechanisms below, things get even better]

                --file descriptors

                --fork/exec() separation

                --very few mechanisms lead to a lot of possible
                functionality

2. Threads

    What is a thread?

    How/why are threads useful?

    Implementation: assume for now: 
        --abstraction created by OS
        --preemptively scheduled

    [draw abstract picture of threads]

    (later, we will explore alternatives)

    Interface to threads:

      *  tid thread_create (void (*fn) (void *), void *); 
            Create a new thread, run fn with arg

      *  void thread_exit (); 

      *  void thread_join (tid thread); 
        
            Wait for thread 'thread' to exit
        
      * plus a lot of synchronization primitives, which we'll see today
      and in the coming classes


3. Intro to concurrency

    There are many sources of concurrency.

    --what is concurrency?
        
        --stuff happening at the same time

    --sources of concurrency

        --computers have multiple CPUs and common memory, so
        instructions in multiple threads can happen at the same time!
 
        --on a single CPU, processes/threads can have their instructions
        interleaved (helpful to regard the instructions in multiple
        threads as "happening at the same time")
   
        --interrupts (CPU was doing one thing; now it's doing another)

    --why is concurrency hard?

        *** Hard to reason about all possible interleavings


    --handout:

        1a:  x = 1 or x = 2.
        1b:  x = 13 or x = 25.
        1c:  x = 1 or x = 2 or x = 3 

        2: incorrect list structure

        3: incorrect count in buffer

        all of these are called race conditions; not all of them are
        errors, though

        --worst part of errors from race conditions is that a program
        may work fine most of the time but only occasionally show
        problems. why?  (because the instructions of the various threads
        or processes or whatevever get interleaved in a
        non-deterministic order.)

        --and it's worse than that because inserting debugging code may
        change the timing so that the bug doesn't show up


    --hardware makes the problem even harder

        --sequential consistency not always in effect

        --sequential consistency means:

            --maintain program order on individual processors

            --ensuring that writes happen to each memory location
            (viewed separately) in the order that they are issued

    --assume sequential consistency until we explicitly relax it