Concurrency examples
CS3841 examples using concurrency techniques
Examples with file names con*.c show the progression of problems that can arise by trying to perform mutual exclusion ourselves without OS support.
Other examples show in sem*.c and mutex*.c show how the OS can help out by providing concurrency mechanisms.
-
race.c - Shows the race condition that can happen then threads try to modify multiple global values at the same time
-
con1.c - Concurrency using "taking turns"
Provides mutual exclusion but does not work for more than 2 processes
Also does not work if a process does not want to access the critical section -
con2.c - Concurrency using flag array - version 1
Allows threads to specify desire for critical secgion
Due to race conditions with the flag array, it cannot guarentee mutual exclusion -
con3.c - Concurrency using flag array - version 2
Move setting of the flag before the wait
Allows threads to specify desire for critical secgion
Due to race conditions with the flag array, it is prone to deadlock if both threads set the flag at the same time -
con4.c - Concurrency using flag array - version 3
Sets the critical section flag before the wait
Allows threads to specify desire for critical secgion
Adds deadlock detection and relase of the flag if both threads have their flag set
Prone to livelock since threads might be constantly releasing their flag -
con_dekkers.c - Concurrency algorithm proposed by Theodorus Jozef Dekker
Combines the deadlock detection of cons4 with the taking turns algorithm in cons1
Ensures mutual exclusion along with deadlock/livelock prevention, however needs to know how many participants there are
Also does not work on modern CPUs that perform out-of-order execution -
sem1.c - Uses semaphores to control access to the critical section
-
sem2.c - Shows that semaphores are NOT locks, but a signalling mechanism. Multiple posts to a semaphore incremenet the count regardless of the current value
-
sem_list1.c - Shows what can happen as a result of uncontrolled access to a singly linked list
-
sem_list2.c - Uses a semaphore as a way to control access to a critical section for a singly linked list
-
mutex1.c - Uses a mutex lock to control access to a critical section that increments two global variables
-
mutex2.c - Shows the undefined behavior that can happen when a thread attempts to unlock a mutex that's already unlocked
-
mutex3.c - Shows the deadlock behavior that can happen when a thread attempts to lock a mutex that it has already locked
-
prod_cons1.c - Shows the producer and consumer problem
When access to a limited shared space is not controlled there are chances where a producer thread might attempt to write when the space is full and a consumer might attempt to read when the space is empty -
prod_cons2.c - Shows the producer and consumer problem
Access is controlled using semaphores
One semaphore counts the number of filled spots
One semaphore counts the number of empty spots
Producers wait for at least one free spot before writing
Consusmers wait for at least one filled spot before reading