Resources:
1)
Problem
What is starvation?
Starvation is when a thread can never access the resources due to faulty programming, or the use of weak semaphores.
2)
Problem
Readers/writers locks is an interesting case for discussing starvation. Why?
The problem: An arbitrary amount of readers can read the resource at the same time, but only one writer can access the resource given that no readers have access to the resource.
Either, the readers might lead to the writers never being allowed to write (thus starving the writer). Or the writers might always take up the resource, leading to starvation of the readers.
3)
Problem
Some times the program prints strange errors in the address list (Sverre Hendseth and Ola Normanns entries are mixed up):
What is the problem?
There is no guarantee that the first and last name is printed sequentially due to the lack of mutexes.
4)
Problem
…and even worse: Occasionally this can happen even inside of words:
What is the problem here?
printf is not guaranteed to be atomic, and can therefore be interrupted by another thread mid print.
5)
Problem
What do we call such errors that occur “occasionally”?
Race conditions.
6)
Problem
We solve the problem by protecting the functions in the module with semaphores. The module now looks like this:
How do using semaphores like this solve the problem?
Semaphores “lock” the resource when doing critical actions, which ensures sequentially when it is needed.
7)
Problem
As the program grows it turns out that the combination of printName() and printAddress() occurs many places in the program (when printing name tags, letterheads, business cards, envelopes,…), and we decide to make the function printNameAndAddress as a part of the module:
Look at the module interface; What do you think about this decision in a code quality perspective?
This is bad code quality, due to the function being too specialized. It is also unnecessary to have a mutex before and after printName and printAddress due to them already having their own mutex.
8) + 9)
Problem
However, this does not work at all: The program never prints any combination of name and address; It just hangs. What happens?
sem_wait of the semaphore PersonSem is used twice in a row (first in the printNameAndAdress, then in printName), making it impossible to get the sem_signal freeing the resource. We get a deadlock.
10)
Problem
In this situation it might be an alternative to drop the semaphore protection of printNameAndAddress? Why would/wouldn’t this be ok?
If we need to print them sequentially, this will not work. We would then need to lock both functions, and remove the internal semaphore in each of the functions / create a new mutex.
11)
Problem
In Ada (that is, not using semaphores) this problem would be easy to solve: Describe shortly how?
Make the module a protected object, and the functions to procedures.
12)
Problem
In Java this problem would be easy to solve: Describe shortly how?
Making the module an object, where the functions (methods) are synchronized.
13)
Problem
With POSIX mutexes the problem does not solve itself; we have to set the mutex in “recursive” mode (PTHREAD_MUTEX_RECURSIVE). How do you think a mutex in this mode works?
14)
Problem
If you really have to protect one of your modules using only semaphores; How would you approach it?