DRAFT |
Thread Synchronization Primitives
Primary Include: SDL_mutex.h
Other Includes: SDL_thread.h, SDL_stdinc.h, SDL_error.h
Contents
Introduction
Functions in this group provide thread synchronization primitives for functions in the Thread Management group.
There are 3 primitives available in SDL, the:
Mutex
If you understand the phrase "mutually exclusive" then you already know the basic idea of a mutex. Mutex, or mutual exclusion, functions are used to protect data structures in multi-threaded processes. By coordinating multiple threads using or calling the same data source a mutex prevents interference between threads that may cause instability in the program. Threads take turns locking the mutex (accessing the resource) one at a time. Waiting threads are queued up based on the mutex algorithm? / based on the OS? and take their turn locking (accessing) the shared resource as each previous thread unlocks (releases) the mutex. Only the thread that has locked the mutex can access the data structure to read or write to it.
Analogy: This is similar to needing a key to access the restroom at a gas station.
*The clerk at the counter who controls access to the key is like the mutex.
*The restroom is like the data structure.
*An individual needing to use the restroom is like a thread.
If someone (a thread) wants to use the bathroom (data structure) they must request permission from the clerk (mutex), who only has 1 key to give out. The person who currently possesses the key (locks the mutex) has access to use the restroom and everyone else must wait. Once the key is returned to the clerk anyone waiting for the restroom may then attempt to get the key from the clerk. Eventually each waiting person will get their turn, but the restroom cannot be used by more than one person at a time in this way. (Please disregard the 'human factor' in this analogy, which allows individuals to break rules. Thankfully computers are much less prone to do so.)
Semaphore
Semaphores have 2 features - they count and they snooze threads. They can either count up from 0 or down from a preset starting point. In both cases the critical value is 0. It indicates that there is nothing available to be worked on. When the count is 0 a semaphore tells waiting threads to sleep until the count is >0. Semaphore functions are used to determine whether a data structure is available to be allocated to a thread, and releases a thread (or threads if the count is >1) to access the data if it is. Because of the potential to permit multiple threads access to the same data, the individual data structures are often protected directly by a mutex and the semaphore acts as a 2nd layer of regulation.
Note that a semaphore can behave much like a mutex if the count never exceeds 1. Like a mutex, a semaphore limited to 1 can only allow 1 thread past its "check point" in the process. This effectively removes the possibility of another thread using the same data simultaneously.
Analogy - counting down: This is similar to waiting in a single line for access to any one of a number of check stands, like you might do at some "big box" stores (ex: Fry's Electronics). There are so many check stands that you can't see which are open for sure, more than one check stand might become available simultaneously, and it would be embarrassing and awkward to leave the line only to find that the space you thought was available isn't and there's nowhere to go. In real life this can be resolved with lights above each check stand to indicate when one is available. The eyes and brains of the customers provide the remainder of the problem-solving. In programming terms, you resolve this with mutexes and a semaphore.
A semaphore is used in lieu of lights to provide a count of available check stands that can be accessed by all the threads (customers) simultaneously. If there are no available check stands then the semaphore tells all the threads (customers) to wait.
A mutex protects each data structure (check stand) from being accessed by more than one thread (customer) at a time.
When the store opens in the morning, the semaphore count indicates the total number of check stands (let's say 8). It remains unchanged until a customer enters the line and checks the semaphore to see if there is an open check stand. Since there are 8 open, and the customer (thread) only needs 1, the customer leaves the line and picks a check stand to use. When the customer enters the check stand (s)he locks the mutex for that stand (in real life this could be equivalent to just taking up the space there). When the mutex is locked and the stand is in use the semaphore is decremented to 7. The next customer to enter the line will see that there are 7 available check stands and can repeat the process. When a customer has completed his/her transaction and unlocks the mutex the semaphore count is then incremented (raised) by 1 to indicate that the stand is now available for another customer. This process repeats for each customer wishing to check out as long as there is at least 1 available check stand. If the store gets busy and the check stands fill up with more customers waiting in line, then the other feature of the semaphore comes into play. Customers in excess of 8 are instructed, by the semaphore, to wait in line until the count is a positive number. When it is, a customer can leave the line and enter an available check stand. If more than one check stand becomes available simultaneously this creates the possibility that more than one customer may leave the line and head for a check stand at the same time. This moves the line along faster but could also result in a jam where two customers are trying to gain access to the same check stand. (Imagine them both putting their purchases on the counter together, getting them mixed up and 'contaminating' each others' purchases.) This is where a mutex becomes valuable. Each check stand has it's own mutex to prevent multiple customers from trying to process their transactions through the same check stand. Whoever locks the mutex first (puts the first item on the counter) gets to use that check stand and the other customer (thread) is blocked and must find another available check stand to complete their transaction. As above, as customers finish transactions and vacate check stands the semaphore is incremented. At the end of the day when all the customers are gone and all the check stands are empty the semaphore will again read 8.
Analogy - counting up: This is similar to a car wash using a counter display to show the number of recently washed cars waiting for the drying team to dry them.
- The cars are what are waiting to be worked on (data available for processing).
- The Dryers (threads) are the people that need to work on the cars (data) next.
The semaphore keeps track of how many cars are waiting and tells the teams to stop and rest if there aren't any.
Under normal circumstances the Dryers dry cars as they come out of the car wash. In most cases the semaphore count would alternate between 0 and 1. However, if something slowed down the drying process (ex: the car wash became very busy and temporarily ran out of dry towels; a number of small cars followed a number of big cars; the drying crew was smaller or slower than usual...) it is possible that a backlog of cars to be dried could form. In that case the semaphore (a big digital display in real life) would continue to increment (count up) as cars exited the car wash, and would decrement (count down) as cars were taken for drying. When the drying teams finally go through the last car and the count was 0 they would be able to take a break.
Condition Variable
Condition variables in SDL are used to monitor the status of other variables and alert waiting functions when there has been a change. (The "variable" that they monitor is the "condition" of another variable.) They do not protect directly like mutexes do (and semaphores can if their max count is 1). Instead they coordinate threads by monitoring for changes and alerting when change occurs. This saves time and resources by preventing threads from trying to work on data that isn't available and from constantly checking data that isn't changing.
Note that a variable the condition variable is monitoring is generally protected by a mutex so that when the condition variable indicates a change, only one thread at a time can read and potentially change the variable.
Analogy: This is similar to getting an alert when you have received a text message. The alert does not tell you who it is from or what it says, just that a message has been received. You have to then look for the details of the message yourself.
The condition variable is the alert telling you that there has been a change in the number of messages in your inbox (the variable being monitored).
- You are like a thread waiting for information in the inbox.
It is useless to keep getting out your phone and checking the inbox if there is nothing new there. Having an alert tell you as soon as something has arrived saves you time and energy and ensures that you know the moment the message becomes available instead of eventually when you get around to checking again. Similarly, condition variables help to keep threads busy when there is something to do but idle when there isn't.
Here is an analogy that utilizes all three primitives together:
Imagine a buffet-style restaurant. You, the customer, (one of the threads) would like to utilize the goods and services (data structures) available at this restaurant. When you enter the restaurant you are first met by a Host(ess) (another thread). (S)He asks for the number of individuals in your party. (S)He assigns your party size to a read-only variable (PartySize=x) that will follow you through the restaurant so no one else has to ask the same question. green
The Host(ess) then checks to see if there is an available table of an appropriate size (TableSize=x).
Semaphores track the number of available tables of each size (ex: 4 of TableSize=2, 8 of TableSize=4, 5 of TableSize=6, etc.).
They are decremented (reduced) from the maximum number of tables of each size as patrons are seated (ex: 4 decremented to 3 of TableSize=2 when a couple is seated).
They are incremented (increased) up to the maximum number as patrons leave and the tables are cleaned for the next guests (ex: 3 incremented to 4 of TableSize=6 when a family leaves).
?? A mutex protects the semaphores from being changed by more than one restaurant worker at a time. (ex: If the Host(ess) is changing the value because a party is being let in then a Busser cannot simultaneously change the value when a table of the same size has just been cleaned. The Busser could, however, change the value for a table of a different size.) ?? green
A condition variable monitors the semaphores for changes. When a semaphore count changes the condition variable alerts the Host(ess) to check the counts to see if a waiting Party can be seated.
The Host(ess) checks the appropriate semaphore for the table size needed for your party (TableSize > PartySize). If the value is 0 you and your party are requested to wait. If the value is >1 your party is allowed to enter the buffet line.
?? The Host(ess) locks the mutex and decrements (reduces the count by 1) the semaphore for that size table, so (s)he knows it is taken and does not accidentally assign it to another party while you are sitting there. ??
The next person you meet is the Buffet Manager (another thread).
- (Please bear with the analogy a little at this point. While this may not occur in a real restaurant, it is not inconceivable and fits the situation well.)
- There are 5 types of hardware (as above) being monitored in this example.
- Each has a variable holding a current count (ex: forks=18, spoons=20, knives=11, etc.)
Each variable is protected by its own mutex. This prevents a Patron from taking hardware (and decrementing the variables) while a busser is refilling the hardware (and incrementing the variables), which may confuse the count.
Each variable is monitored by a single condition variable that watches for the values to change. A change in any one variable triggers the condition variable, which alerts the Buffet Manager to check and see if there is now enough hardware to send the next party through.
- There are 3 categories of people who interact directly with the hardware.
- Patrons who take hardware to use and cause the count to be decremented.
- Bussers who bring clean hardware back and cause the count to be incremented.
- The Buffet Manager who reads the variable counts and ensures that there is sufficient hardware before sending a party through the buffet line.
In order to know when it is OK to send a party through the buffet, the Buffet Manager must check the hardware variables and compare them to the PartySize variable for your party (all counts must be > PartySize). If the initial check when your party approaches finds the counts too low the Buffet Manager waits on the condition variable and your party (thread) waits in line.
Because of the mutex the Buffet Manager can only view the current counts when no one else is interacting with the hardware. This ensures that the Buffet Manager is basing his/her decision to send a group back on current, accurate counts.
If your party has to wait, you will wait until the condition variable alerts the Buffet Manager that a hardware count has changed. (This is more efficient than requiring the Buffet Manager to constantly check for changes or having only periodic checks that may leave available hardware sitting unused and Patrons waiting in line unnecessarily.) This alert tells the Buffet Manager to check the numbers again to see if the count has become high enough for each type of hardware to let the next party through the buffet line. If, following an alert, there is still not enough hardware ready for the next party, then the Buffet Manager can go back to other tasks and ignore the counts until another alert from the condition variable comes through. Once there are enough pieces of hardware available for the next party to pass through, the Buffet Manager ushers them to the buffet line.
