Question 1: Launch this program several times. What do you notice? Explain it!
The result can be other than 3000 sometimes, that’s because when the thread is
not synchronize , multiple workers can access to the variable and make the increase amount
different each the program is executed

Question 2: Change the code of the general executable program by replacing
ThreadedWorkerWithoutSync with ThreadedWorkerWithSync to initiate three
instances worker1-3. What is the difference between the output of this program
and that of question 1? Explain it!
The result is always 3000 as the thread is synchronize, so at one particular time
there is only one worker access to variable

Question 3: Change the code of the general executable program by replace the
instances worker1-3. What is the difference between the output of this program
and the output in question 1? Explain it!
The result is always 3000, because with ThreadedWorkerWithSync class,instead of being given access to variable every time the exploit() method was called, a worker can be given access only when the variable is free(meaning it is not accessed by any worker at the moment),the variable will be then locked to the worker ,and when the operation has been done(increase by 1),it will be unlocked.

Question 4: Complete this file above (in the part YOUR-CODE-HERE) with a loop
to increase the variable shared by 1 for 5 seconds.
(hint: time(NULL) will return the present system time in second).
    while(time(NULL)<=end)
    {
        shared++;
        sleep(1);
    }

Question 5: Try to increase the value of threads and the value of the constant
NUM_TRANS after each execution time until you obtain the different results
between Balance and INIT_BALANCE+credits-debits. Explain why do you get this
difference.
For every time the program is executed, all the threads run simultaneously while also having access to the same variables at the same time.
Even for a simple addition command, for example balance = balance + v; there’s still 2 steps for each thread to do: calculate balance + v and store it to a temp variable, then assign the value of temp back to balance
Because there’s no resource locking, the value of balance can even be changed between the time the 2 steps is done in a thread, since another thread could finish its job earlier
This resulted in all the variables have different values each time the program is done executing

Question 6: Try to build and run this program. Launch it repeatedly until you see
the difference between Shared and Expect values. Analyze the source code to
understand the problem that leads to this difference.
Consider the code block for locking
    for (i = 0; i < 100; i++)
    {
        //check lock
        while (lock > 0);     //spin until unlocked
        lock = 1; //set lock
        shared++; //increment
        lock = 0; //unlock
    }
Because all threads are spinning in the while loop waiting for the lock to be open at the same time, there’s a chance that a thread swap can happen after the loop is stopped, leading to 2 or more threads can have the lock.

Question 7: Now, you have to modify the code of the file without-lock.c in
implementing the mutex lock above (you can name it differently like mutex-lockbanking.c). Try to launch it repeatedly and evaluate the obtained output. What is the improvement after using mutex lock?
The total balance now matches the expected value based on the credit and debit
Credits:        586
Debits:        13020

50+586-13020=   -12384
Balance:       -12384

Question 8: compare the run times of the two strategies to prove that Fine
Locking is faster and much faster on larger load sets


Question 9: Run this program and what do you get as output? Explain what the
deadlock is.