Question

I thought thread safe, in particular, means it must satisfy the need for multiple threads to access the same shared data. But, it seems this definition is not enough.

Can anyone please list out the things to be done or taken care of to make an application thread safe. If possible, give an answer with respect to C/C++ language.

Answer 1

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.