how to make an application thread safe?

There are several ways in which a function can be thread safe.

It can be reentrant. This means that a function has no state, and does not touch any global or static variables, so it can be called from multiple threads simultaneously. The term comes from allowing one thread to enter the function while another thread is already inside it.

It can have a critical section. This term gets thrown around a lot, but frankly I prefer critical data. A critical section occurs any time your code touches data that is shared across multiple threads. So I prefer to put the focus on that critical data.

If you use a mutex properly, you can synchronize access to the critical data, properly protecting from thread unsafe modifications. Mutexes and Locks are very useful, but with great power comes great responsibility. You must not lock the same mutex twice within the same thread (that is a self-deadlock). You must be careful if you acquire more than one mutex, as it increases your risk for deadlock. You must consistently protect your data with mutexes.

If all of your functions are thread safe, and all of your shared data properly protected, your application should be thread safe.

As Crazy Eddie said, this is a huge subject. I recommend reading up on boost threads, and using them accordingly.

low-level caveat: compilers can reorder statements, which can break thread safety. With multiple cores, each core has its own cache, and you need to properly sync the caches to have thread safety. Also, even if the compiler doesn't reorder statements, the hardware might. So, full, guaranteed thread safety isn't actually possible today. You can get 99.99% of the way there though, and work is being done with compiler vendors and cpu makers to fix this lingering caveat.

Anyway, if you're looking for a checklist to make a class thread-safe:

• Identify any data that is shared across threads (if you miss it, you can't protect it)
• create a member boost::mutex m_mutex and use it whenever you try to access that shared member data (ideally the shared data is private to the class, so you can be more certain that you're protecting it properly).
• clean up globals. Globals are bad anyways, and good luck trying to do anything thread-safe with globals.
• Beware the static keyword. It's actually not thread safe. So if you're trying to do a singleton, it won't work right.
• Beware the Double-Checked Lock Paradigm. Most people who use it get it wrong in some subtle ways, and it's prone to breakage by the low-level caveat.

That's an incomplete checklist. I'll add more if I think of it, but hopefully it's enough to get you started.

Two things:

1. Make sure you use no globals. If you currently have globals, make them members of a per-thread state struct and then have the thread pass the struct to the common functions.

For example if we start with:

// Globalsint x;int y;// Function that needs to be accessed by multiple threads// currently relies on globals, and hence cannot work with// multiple threadsint myFunc(){    return x+y;}

Once we add in a state struct the code becomes:

typedef struct myState{   int x;   int y;} myState;// Function that needs to be accessed by multiple threads// now takes state structint myFunc(struct myState *state){   return (state->x + state->y);}

Now you may ask why not just pass x and y in as parameters. The reason is that this example is a simplification. In real life your state struct may have 20 fields and passing most of these parameters 4-5 functions down becomes daunting. You'd rather pass one parameter instead of many.

2. If your threads have data in common that needs to be shared, then you need to look into critical sections and semaphores. Every time one of your threads accesses the data, it needs to block the other threads and then unblock them when it's done accessing the shared data.

If you want to make a exclusive access to the class' methods you have to use a lock at these functions.

The different type of locks:

Using atomic_flg_lck:

class SLock{public:  void lock()  {    while (lck.test_and_set(std::memory_order_acquire));  }  void unlock()  {    lck.clear(std::memory_order_release);  }  SLock(){    //lck = ATOMIC_FLAG_INIT;    lck.clear();  }private:  std::atomic_flag lck;// = ATOMIC_FLAG_INIT;};

Using atomic:

class SLock{public:  void lock()  {    while (lck.exchange(true));  }  void unlock()  {    lck = true;  }  SLock(){    //lck = ATOMIC_FLAG_INIT;    lck = false;  }private:  std::atomic<bool> lck;};

Using mutex:

class SLock{public:  void lock()  {    lck.lock();  }  void unlock()  {    lck.unlock();  }private:  std::mutex lck;};

Just for Windows:

class SLock{public:  void lock()  {    EnterCriticalSection(&g_crit_sec);  }  void unlock()  {    LeaveCriticalSection(&g_crit_sec);  }  SLock(){    InitializeCriticalSectionAndSpinCount(&g_crit_sec, 0x80000400);  }private:  CRITICAL_SECTION g_crit_sec;};

The atomic and and atomic_flag keep the thread in a spin count. Mutex just sleeps the thread. If the wait time is too long maybe is better sleep the thread. The last one "CRITICAL_SECTION" keeps the thread in a spin count until a time is consumed, then the thread goes to sleep.

How to use these critical sections?

unique_ptr<SLock> raiilock(new SLock());class Smartlock{public:  Smartlock(){ raiilock->lock(); }  ~Smartlock(){ raiilock->unlock(); }};

Using the raii idiom. The constructor to lock the critical section and the destructor to unlock it.

Example

class MyClass {   void syncronithedFunction(){      Smartlock lock;      //.....   }}

This implementation is thread safe and exception safe because the variable lock is saved in the stack so when the function scope is ended (end of function or an exception) the destructor will be called.

I hope that you find this helpful.

Thanks!!