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:

// Globals
int x;
int y;

// Function that needs to be accessed by multiple threads
// currently relies on globals, and hence cannot work with
// multiple threads
int 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 struct
int 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.