Thread Safety in C++ code

Thread Safety in C++ code

• Rober7

  Critical section objects are initialized as the parameter to InitializeCriticalSection, and not through assignment. Therefore, static initialization isn't really the main issue.

  Given a function such as

  void foo()
  {
      static CRITICAL_SECTION cs;
      InitializeCriticalSection(&cs);
  }

  we are at the mercy of another problem. Calling InitializeCriticalSection on an already created critical section causes undefined behavior. So, if you are to include the initialization to the function itself, you need a second static variable to flag wheter or not the section has already been initialized.

  void foo()
  {
      static CRITICAL_SECTION cs;
      static bool initialized = false;
      if(!initialized)
      {
          initialized = true;
          InitializeCriticalSection(&cs);
      }
  }

  This takes us one step further, but the if construct is obviously not thread safe, and undefined behavior awaits once more. To solve the issue, we can look to InterlockedIncrement, in a manner such as this.

  void foo()
  {
      volatile static long initialized;
      static CRITICAL_SECTION cs;

      if(InterlockedIncrement(&initialized) == 1)
      {
          InitializeCriticalSection(&cs);
      }
      initialized = 1;

      EnterCriticalSection(&cs);
      /* Do synchronized operation */
      LeaveCriticalSection(&cs);
  }

  From the top:

  Being of static intrinsic type, initialized will be set to 0, with no race condition (it doesn't happen inside the function). The same goes for the critical section. No code, no problem.

  The interesting part is InterlockedIncrement. This function will use a lock prefix to assure that no two calls, "simultaneous" or not, will return the same number. We can therefore safely see if the return value is 1, which would indicate that it was previously 0 (duh), and that the critical section has not been initialized. After calling ICS, we reset initialized to 1, to avoid problems caused by an type overflow (if you should happen to call the function 2^32 times).

  Having done that, we're all good enter the critical section, and do whatever needs to be done.

  This approach is however not the best one seen from neither a design point of view, or with regard to efficiency. You will be getting a bunch of extra operations for each call to foo(), which wouldn't be needed if the critical section was moved outside the function scope. But you do get what you ask for :)

  
  
  

• none33333333

  Hi einaros, Thanks for your reply. This is helpful.
  
  
• Thread Safety in C++ code