> HW5
> released: 02/16, 11:00
> due: 02/22, 23:59
> 
> Answer the following questions.
> Submit your answers to Canvas assignments.
> There is an entry for this homework.
> 
> 
> 1. Six commandments (3 points)
>    Have you read Mike Dahlin's "Basic Threads Programming: Standards and Strategy"?
>    Answer "Yes" if you do; otherwise, "No" (then you will lose points).
> 

[If you answer "Yes", you will get points.]

> 
> 
> 2. OSTEP (4 points)
>    Read OSTEP chapter 30 (https://pages.cs.wisc.edu/~remzi/OSTEP/threads-cv.pdf)
>    and answer the following questions.
> 
>    2.a. (2 point)
>      Why do we need condition variables? Aren't mutexs enough?
>      Explain in two sentences.
> 

To avoid "busy waiting".
Recall the soda example in class where we have 100 student consumers and one producer.
[Anything with the similar idea gets points.]

> 
>    2.b. (2 point)
>      Read Figure 30.8.
>      What can go wrong using "if" (line 9 and 21)?
>      Explain in a few sentences.
> 

As OSTEP mentioned (see also Fig30.9), with multiple consumers and producers,
being "signaled" is not a sufficient condition for the thread to moving
forward. It is possible that a producer being wake up because of an empty slot,
but the slot is immediately filled by other producers. You should always use
"while" to check the condition.
[Anything with the similar idea gets points.]

> 
> 
> 3. Four-step solving process (3 points)
> 
>    Read the "database reader/writer problem" below and write down the first three
>    steps of our 4-step problem solving strategy.
> 
>    Problem:
>    - We have a database.
>    - There are readers and writers: 
>      -- readers will read data from the database.
>      -- writers will write data to the database.
>    - We need to give writers **exclusive access**:
>       a single active writer means there should be no other writers and no readers.
>    - We allow multiple readers:
>       multiple reads can read the database at the same time.
>    - This is a question in our handout and the code-level solution is here:
>       (https://naizhengtan.github.io/23spring/notes/handout_w06a.pdf)
> 
>    Please write down the first three steps of your design of this problem:
>    [hint: the 4 steps are:
>       1. Getting started:
>          1a. Identify units of concurrency.
>          1b. Identify shared chunks of state.
>          1c. Write down the high-level main loop of each thread.
>       2. Write down the synchronization constraints on the solution.
>       3. Create a lock or condition variable corresponding to each constraint
>       4. Write the methods, using locks and condition variables for coordination
>    ]
>
>    [update 02/21:
>     We expect to see English sentences for all the steps above.
>
>     For step 2, there are two types of "synchronization constraints":
>     (a) mutual exclusion and (b) scheduling constraints.
>       * For (a), it is something like, "among multiple entities (i.e., ABC,
>         XYZ), only one can do something."
>       * For (b), it is something like, "only when something happens, then can
>         XYZ do something." or "if something happens, then XYZ should wait until
>         other things happen."
>    ]


 [below is one possible answer.]

 1. Getting started
     a. what are units of concurrency? [readers/writers]
     b. what are shared chunks of state? [database]
     c. what does the main function look like?

        --read()
          check if writers exist
             (wait until no writers)
          access DB

        --write()
          check if readers or writers exist
              (wait until no readers or writers)
          access DB

 2. and 3. Synchronization constraints and objects

        --only one thread manipulates reader/writer numbers at a time;
          only one thread modifies DB at a time.
          NOTE: **this does not mean only one thread in the DB at a time**
          (use mutex)

        --reader can access DB when no writers
          (use a condition variable: okToRead)

        --writer can access DB when no other readers or writers
          (use a condition variable: okToWrite)