Finish Lab 4

Lab4/Lab4.c

@@ -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);
@@ -98,7 +109,4 @@ int main(int argc, char **argv) {
 	sem_destroy(&sem);
 
 	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