Question

We all know about semaphore and critical section problem.

In pthreads, this can be sorted by using pthread_mutex_lock( ) and pthread_mutex_unlock( ).

But why do we need these system calls, when the same can be implemented in the code, by doing something like:

flag = 0;
if (flag) // Thread1 enters and makes flag = 0
{
   flag = 0; // On entering critical section, flag is made 0 so that others can't enter
  // do some critical section operation
  flag = 1;
}
// Thread1 exits

Doing the same as above, will it solve the critical section problem? If no, then why?

Answer 1

There are probably many reasons why pthread_mutex objects and APIs that manipulate those objects are used instead of everyone coding up their own synchronization primitives. A coupl eof the more important ones:

• much like many other objects and functionality that are useful to a wide audience, it makes sense to standardize that functionality so that people don’t have to reinvent the wheel and so they can use and recognize standard patterns and idioms. In other words, there are pthread mutex APIs for the same reason there are standard string manipulation functions.

• synchronization techniques are notoriously complicated and difficult to get right. So it’s best to have a vetted library of code that performs this functionality. Even if it were OK to reinvent the wheel umpteen million times, having 99% of those implementations with serious flaws isn’t a great situation. For example, pthreads handles issues like memory barriers and atomicity which are not addressed properly in the example you have in your question. Considering the example in the question: there’s at least one serious problem; it has a race condition where two threads could enter the critical section concurrently since the test of the flag and setting it to 0 aren’t performed atomically.