NOTES FOR LAB1:

1.  If several processes are waiting on I/O, you may assume
noninterference.  For example, assume that on cycle 100 process A
flips a coin and decides its wait is 6 units and next cycle (101)
process B flips a coin and decides its wait is 3 units.  You do NOT
have to alter process A.  That is, Process A will become ready after
cycle 106 (100+6) so enters the ready list cycle 107 and process B
becomes ready after cycle 104 (101+3) and enters ready list cycle 105.

2. PS (processor sharing).  Every cycle you see how many jobs are
in the ready Q.  Say there are 7.  Then during this cycle (an exception
will be described below) each process gets 1/7 of a cycle.

EXCEPTION: Assume there are exactly 2 jobs in RQ, one needs 1/3 cycle
and one needs 1/2 cycle.  The process needing only 1/3 gets only 1/3,
i.e. it is finished after 2/3 cycle.  So the other process gets 1/3
cycle during the first 2/3 cycle and then starts to get all the cpu.
Hence it finishes after 2/3 + 1/6 = 5/6 cycle.  The last 1/6 cycle is
not used by any process.

This shows that PS is not so easy to simulate (it is the easiest to
analyze).  For this reason I have moved it from required to extra credit

2.  PS moved from required to extra credit 

How get atomicity.

    For uniprocessor, disable interrupts

    For multiprocessor, harder

Deadlock

    No thread can make progress.

    Simple example is using two semaphores in opposite order in
    different threads.

    Different from livelock and starvation

    Subject of chapter 7

Binary vs Counting Semaphores

    What we did were counting semaphores.

    Special case where semaphore can only take on two values
    is called a binary semaphore

    The code in the book for implementing a counting semaphore using
    just binary semaphores is clearly wrong since it has signal(S2)
    but no wait(S2).  I guess the signal(S1) on p180 should be
    wait(S2).  I prefer a different algorithm, but we will skip it.

    Easy trick with two BINARY semaphores to get alternation.

Bounded Buffer Problem (aka Producer Consumer)

    When the two semaphore trick is used with COUNTING semaphores
    (same initial value) get bounded buffer
    
    loop
        produce item
        wait(empty)
        wait(mutex); insert item in buffer; signal(mutex)
        signal full
    
    loop
        wait(full)
        wait(mutex); remove item from buffer; signal(mutex)
        consume item
        signal(empty)
            
Readers writers problem

    Readers permit concurrency

    Writers demand exclusivity

    Solutions in this course slightly serialize readers
    
    The following solution can starve writers (and readers if the
    semaphore is not fair).

    There are (writer-priority) variants that don't,
    can but starve readers.

    There are fair variants that won't starve any process.

    loop
        wait(writer_sem)     *** binary semaphore
        write
        signal(writer_sem)

    loop
        wait(#readers_sem)   *** binary semaphore
        #readers++
        if(#readers) = 1
            wait(writer_sem)
        signal(#readers_sem)
        read
        wait(#readers_sem)
        #readers--
        if (#readers = 0)
            signal(writer_sem)
        signal(#readers_sem)

Dining Philosophers Problem

    5 philosophers

        Each has an infinite loop of (think; hungry; eat)

    round table with chopstick between phils and rice in middle

    philos must get two chopsticks to eat

    natural algorithm (get left; get right; eat; down left; down
    right) deadlocks

        get is wait

        down is signal

    (kludgy fixes)

        Max 4 can sit down

        Crit sect to see if both sticks avail and pick up both

            need fair CS or can livelock

            better to use reader-writer with upgrade to writer

        Different phils act differently (e.g. even numbered phils
        start with right)

---------------- Higher level concurrency control ----------------

Critical regions

    shared v
    ...
    region v
    ...
    end

Conditional critical region

    New stmt.  await bool-expr                
    
    If bool-expr false,
    Switch to new task with mut exclusion dropped for current task

    When return to current task assure bool-expr true

    If permit await anywhere,
    user must assure that whatever was done prev inside region
    is still true.

    If permit await only as first stmt, don't have above concern.

        Book calls this case critical region and has slightly
        different syntax.

    When should one check if bool-expr is true?

        Not trivial, we skip.

ADA

    Rendezvous

Monitors

    Handout picture (on web as well)

    Encapsulate date and operations

        Ada package; C++ class    

    Mutual Exclusion

    Fifo (so fair)

    "Condition" variables with wait/signal operations

    If wait gets bad news process leaves monitor but
    gets higher prio to reenter than new monitor call

    On signal who runs?

        Common is to run waiter but place signaler in highest
        priority (urgent) queue.

        Don't have this problem is signal is last stmt.

    For nested monitors, when wait on inner do you release outer.

HOMEWORK 6.7 PSEUDOcode
         6.12