Finish Lab 4

This commit is contained in:
Isaac Shoebottom 2023-10-25 12:08:03 -03:00
parent bcd7364d14
commit 38ba9792a3

View File

@ -1,13 +1,24 @@
/*
* Question 2: You see the number 1 most of the time. It is sometimes different because there are periods of time when the threads are reading/writing to the same place, but with the number of increments being 100, it is not likely that the threads will be reading/writing at the same time. In the CPU what happens is that a value is loaded into a register, while another thread completes a task, and then the value is written back to the memory. This leads to missing increments/decrements.
* Question 2: You see the number 1 most of the time. It is sometimes different because there are periods of time when
* the threads are reading/writing to the same place, but with the number of increments being 100, it is not likely that
* the threads will be reading/writing at the same time. In the CPU what happens is that a value is loaded into a
* register, while another thread completes a task, and then the value is written back to the memory. This leads to
* missing increments/decrements.
*
* Question 4: You see the number 1 often. Since the number of increments is 1000, the chance has increased for threads to be reading/writing at the same time. This leads to more missing increments/decrements.
* Question 4: You see the number 1 often. Since the number of increments is 1000, the chance has increased for threads
* to be reading/writing at the same time. This leads to more missing increments/decrements.
*
* Question 6: You see the number 1 almost never. The number of loops at this point almost guarantees that the threads will be reading/writing at the same time, and the counter missing increments/decrements.
* Question 6: You see the number 1 almost never. The number of loops at this point almost guarantees that the threads
* will be reading/writing at the same time, and the counter missing increments/decrements.
*
* Question 8: The number 1 is the only thing displayed. This is because the mutex lock ensures that the threads will not be reading/writing at the same time, and the counter will not miss increments/decrements. When another thread tried to lock the mutex, it waits for it to first become unlocked, ensuring proper thread synchronization.
* Question 8: The number 1 is the only thing displayed. This is because the mutex lock ensures that the threads will
* not be reading/writing at the same time, and the counter will not miss increments/decrements. When another thread
* tried to lock the mutex, it waits for it to first become unlocked, ensuring proper thread synchronization.
*
* Question 13:
* Question 13: The program no longer finishes, because the semaphore is waiting for the other thread to increment it,
* but the other thread finishes incrementing it before the first thread gets the chance to print more than 3 times.
* The minus function prints twice at the end because the print comes before the semaphore wait, so there is one minus
* for each plus, plus one minus before it has to wait for the semaphore. This situation is called a deadlock.
*/
@ -57,7 +68,7 @@ void *plus(void *argg) {
int interval = RANDOM_WITHIN_RANGE(100000, 500000, seed);
int i = 0;
for (i = 0; i < 10; i++) {
for (i = 0; i < 3; i++) {
printf("+");
usleep(interval);
sem_post(&sem);
@ -99,6 +110,3 @@ int main(int argc, char **argv) {
return 0;
}
//TODO: Delete this comment
//Semaphore doesn't work because it increments the semaphore all at once before the other thread even gets the chance to print
//Just as an example to fix it you would need two semaphores so you can signal back and forth between the two threads