Is a shared list between multiple threads a race condition?

I've got some multi threaded code that typically runs great, but every so often it will break. I'm trying to pinpoint the problem, but using OpenMP is making that more difficult (the problem does not occur in serial). I know that multiple access to a variable (race conditions) often crashes a program.

I've got a list shared between the multiple threads, and I'm curious if the push_back() on that list is a candidate for a race condition, therefore crashing my program every once in a while? If so, are there any recommendation on how to handle this?
- Speed is of the utmost importance
- I know that using #pragma omp critical would solve a race condition, but potentially slow down the application (there are two lists, so I need a critical rather than atomic).

The only reason I'm not sure about this is because I ran a couple tests, using stl containers, but never got the test code to crash.

Any suggestions would be greatly appreciated!
Thank you in advance,

Solution

Disclaimer: I know nothing about OpenMP specifically. However I can say that yes, two threads doing push_back (or any other modifying operation) on a list at the same time will cause problems, just the same as for a single variable.

I don't know what tools OpenMP gives you for protecting against this. Some common approaches to avoiding this problem:

Put a lock (eg a mutex) around operations on the variable.
Give each thread its own copy of the list, and have them remain independent. At the end of the process, as a separate step, you can merge the results from the different threads. (This is Map-Reduce, pretty much).

The second approach can give better results if you have many threads, and if it fits with your algorithm. Some algorithms can't be structured that way.

If you don't have many threads, depending on the size of your loop body, a simple lock might be the most effective solution.