rsnd

Data corruption. I have come across those heaps of times in my programming life. But all of them were cases when I was handling same external entitity from dfferent threads. e.g. writing to a file or console output. Just wondering how much it affects shared variables? e.g. say I have a boolean/char* variable whose value is set from one thread and another thread is constantly cheching the value of that variable and also witing to that variable do stuff acordingly. My application seems to be running fine at the moment...but can I expect errors to occur in the long term?

__________________
Spread your wings and fly! Chicken!

grumpy

The short answer is: yes.

If you don't prevent strange occurrences, their likelihood is non-zero and they can occur in the long term. The basic guideline for managing variables that are read and modified by multiple threads is to be deliberately paranoid: you must assume any thread doing something with a shared variable will be preempted by another thread doing something else with that variable, with a result that the actions of either thread may be corrupted.

The main problems will arise if two threads attempt to write to the variable concurrently, or if one thread attempts to read it while another is writing it. In general, the concurrent operations are not atomic (unless you use system specific constructs to make them atomic), so the value in the variable can be indeterminate in such cases. The effects are more likely to be visible for strings that are shared between threads as most string operations in C/C++ involve a loop to copy bytes, which means a longer stream of operations to be preempted part way (eg a thread that is writing to a string may be interrupted part way by a thread that reads it: the thread doing the reading will see a strange string). This will often be less obvious for simple types (eg bool) as reading/writing simple types involves less individual operations (eg machine instructions), but can still mean unpredictable results for all affected threads.

In general, you need to GUARANTEE that the act of writing a variable shared between threads can NEVER be interrupted by some other operation (eg reading or writing), AND vice versa. Mutual exclusion locks (eg critical sections, mutexes) are one way. Another way is to only modify the variables at a time when other threads are guaranteed not to be running (eg before the thread is created).

Note: this is a threading question, not a C++ question. C++ includes nothing native related to threads. The answer above is independent of programming language.

prolog

As an extension to grumpy's good answer. This situation when two or more threads access the same shared resource and you do lock mutually exklusive u have to make sure not to develop race-conditions during operation. That is that the resource is locked and altered by one thread and then released. The other thread relies on the resource to have a defined and static sequenced order that was now altered by the other thread before this one resumes. In this case the second thread may miss sth. You also have to be aware of deadlocks that can accure. Allways check that a mutex is released in all cases. Otherwise the other threads will not be able to aquire the resource anymore. If you are interested in such problem google for dijkstra's dining philosophers problem.

__________________
-= C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do succeed, you will blow away your whole leg. =- Bjarne Stroustrup