1522 Order Completed 97 % Response Time 94 Reviews Since 2013

# C Programming Homework Helper

NYC, USA

## Walker D

PhD. in Programming, University of New York, USA

### Profession

C Programming Homework Helper

### Skills

Get Free Quote

Your Order has been sent successfully. We will contact you as soon as possible.

## Simulation in C

The first version of the C code simulates 100 people to do 1000 tasks repeatedly without the usage of the mutex. The following are the statistical results after running the program 10 times:
 Run Number Final Counter Value Total Runtime (seconds) 1 1000 0 2 1001 1 3 1000 0 4 1000 1 5 1001 0 6 1000 0 7 1002 0 8 1000 1 9 1000 0 10 1000 0 Average 1000.3 0
Given the above statistical values, it shows that the final counter value is not being calculated correctly because the supposed expected final counter value is 100,000. Updating the counter is 3 steps:
1. Let new value be the current value of counter plus 1.
2. Do something for a few microseconds.
3. Update the counter to the new value.
Without synchronization, each thread will hold a wrong value in step 1 and use it to update the current value thus in the next round will also result in an invalid value.

### Version 2

The second version of the program simulates 100 people to do 1000 tasks repeatedly with the usage of a mutex. The mutex protects the counter variable (mutex is inside the for-loop). Unfortunately, the program is running forever.  To shorten the time of the experiment. The program is updated to make each person to 50 tasks instead of 1000. The following is the result:
 Run Number Final Counter Value Total Runtime (seconds) 1 5000 4 2 5000 4 3 5000 3 4 5000 2 5 5000 2 6 5000 3 7 5000 4 8 5000 3 9 5000 2 10 5000 3 Average 5000 3
From the output above, it shows that the final counter value is computed correctly. Values are correctly calculated because the codes that would need to update the counter variable is protected by a mutex. It means that threads cannot simultaneously update the counter variable, they have to do it one at a time.

### Version 3

The third version of the program is a modified version 2 program. The program simulates 100 persons to do 50 tasks repeatedly where the mutex is placed outside the for-loop. The following is the result:
 Run Number Final Counter Value Total Runtime (seconds) 1 5000 3 2 5000 3 3 5000 3 4 5000 3 5 5000 2 6 5000 3 7 5000 2 8 5000 3 9 5000 3 10 5000 3 Average 5000 2.8
Similar to version 2, the final counter value is still correctly calculated. This shows that version 3 is faster than version 2. The reason why it is faster than version 2 is that the mutex is placed outside the for-loop. Doing a "lock" and "un-lock" of mutex takes some extra time and this is the reason why version 2 is slower. For every before and after update of the counter variable, version 2 will have to lock-unlock the mutex. Version 3 is faster because a thread will lock the mutex once, complete all the tasks then unlocks it for other threads to use it too. However, this is only valid for this experiment. We cannot generally conclude in other projects that putting the mutex outside the for-loop will always yield to a faster result. The reason why it is faster in this experiment is that the body of the for-loop is short and simple. In the real world, a thread will do longer and many complex tasks and we cannot say that putting the mutex outside the for-loop will yield faster results. If we put the mutex outside the for-loop and if the body of the loop is long, then other threads will starve and wait for a long time and there’s no fair share use of resources. Version 1 is the fastest among the 3 because there's no use of mutex (no overhead time). However, it yields to invalid calculations when handling shared variables. Mutex is always necessary when threads share a variable. Mutex is not needed if each thread will not share data.