Question

The curses display library is considered not to be “thread safe”. Two
software architectures that will ensure that curses library functions
are called safely are:
• Place all curses calls within a mutex guard; or
• Place all curses calls in a single “screen management” thread.
i. Sketch some example code to illustrate the first approach.

ii. Consider the second approach: how might the threads that
are calculating what needs to be updated communicate those
updates to the screen-management thread? Draw a blockdiagram that shows the architecture for this approach.

iii. List the advantages and disadvantages of each approach.

Answer 1

The first approach(Mutex guard) is used to prevent simultaneous execution of a critical section (a piece of code that accesses a shared resource) by multiple threads. In C++, std::mutex class can be used to protect shared data from concurrent access by more than one thread of execution. It is based on locking and unlocking mechanism. Once a mutex is locked, the currently executing thread will own the resource until it is unlocked. Which means that no other thread can execute any instructions until mutex unlocks the block of code surrounded by it.

Use of mutex to solve the synchronization problem:

1. class Race_condition  
2. {  
3. public:  
4.     std::mutex mutex;  
5.     int n;  
6.     Race_condition() :n(0) {}  
7.     void increment() {  
8.     mutex.lock();  
9.     ++n;  
10.     mutex.unlock();  
11.     }  
12. };  

Advantages of mutex:

1. Easy to implement: Mutexes are just simple locks that a thread obtains before entering its critical section, and then releases it.

2. Gurantee synchronization: Since only one thread is in its critical section at any given time, there are no race conditions and data remain consistent.

Disadvantages of mutex:

1. If a thread obtains a lock and goes to sleep, or is preempted, then the other thread may never be able to move forward. This will hold true until the thread handling lock will be scheduled again. It may lead to starvation.

2. Cannot be locked or unlocked from a different context than the one that acquired it.

3. Only one thread is allowed in the critical section at a time.

4. Normal implementation leads to busy-waiting which wastes CPU time.