Real dangers of 2+ threads writing/reading a variable

What are the real dangers of simultaneous read/write to a single variable?

If I use one thread to write a variable and another to read the variable in a while loop and there is no danger if the variable is read while being written and an old value is used what else is a danger here?

Can a simultaneous read/write cause a thread crash or what happens on the low开发者_Python百科 level when an exact simultaneous read/write occurs?

If two threads access a variable without suitable synchronization, and at least one of those accesses is a write then you have a data race and undefined behaviour.

How undefined behaviour manifests is entirely implementation dependent. On most modern architectures, you won't get a trap or exception or anything from the hardware, and it will read something, or store something. The thing is, it won't necessarily read or write what you expected.

e.g. with two threads incrementing a variable, you can miss counts, as described in my article at devx: http://www.devx.com/cplus/Article/42725

For a single writer and a single reader, the most common outcome will be that reader sees a stale value, but you might also see a partially-updated value if the update requires more than one cycle, or the variable is split across cache lines. What happens then depends on what you do with it --- if it's a pointer and you get a partially updated value then it might not be a valid pointer, and won't point to what you intended it to anyway, and then you might get any kind of corruption or error due to dereferencing an invalid pointer value. This may include formatting your hard disk or other bad consequences if the bad pointer value just happens to point to a memory mapped I/O register....

In general you get unexpected results. Wikipedia defines two distinct racing conditions:

A critical race occurs when the order in which internal variables are changed determines the eventual state that the state machine will end up in.

A non-critical race occurs when the order in which internal variables are changed does not alter the eventual state. In other words, a non-critical race occurs when moving to a desired state means that more than one internal state variable must be changed at once, but no matter in what order these internal state variables change, the resultant state will be the same.

So the output will not always get messed up, it depends on the code. It's good practice to always deal with racing conditions for later code scaling and preventing possible errors. Nothing is more annoying then not being able to trust your own data.

Two threads reading the same value is no problem at all.

The problem begins when one thread writes a non-atomic variable and another thread reads it. Then the results of the read are undefined. Since a thread may be preempted (stopped) at any time. Only operations on atomic variables are guaranteed to be non-breakable. Atomic actions are usually writes to int type variables.

If you have two threads accessing the same data, it is best practice + usually unavoidable to use locking (mutex, semaphore).

hth

Mario

Depends on the platform. For example, on Win32, then read and write ops of aligned 32bit values are atomic- that is, you can't half-read a new value and half-read an old value, and if you write, then when someone comes to read, either they get the full new value or the old value. That's not true for all values, or all platforms, of course.

Result is undefined.

Consider this code:

global int counter = 0;


tread()
{
   for(i=0;i<10;i++)
   {
       counter=counter+1;
   }
}

Problem is that if you have N threads result can be anything between 10 and N*10. This is because it might happen all treads read same value increase it and then write value +1 back. But you asked if you can crash program or hardware.
It depends. In most cases are wrong results useless.

For solving this locking problem you need mutex or semaphore.

Mutex is lock for code. In upper case you would lock part of code in line

counter = counter+1;

Where semaphore is lock for variable

counter 

Basicaly same thing for solving same type of problem.

Check for this tools in your tread library.

http://en.wikipedia.org/wiki/Mutual_exclusion

The worst that will happen depends on the implementation. There are so many completely independent implementations of pthreads, running on different systems and hardware, that I doubt anyone knows everything about all of them.

If p isn't a pointer-to-volatile then I think that a compiler for a conforming Posix implementation is allowed to turn:

while (*p == 0) {}
exit(0);

Into a single check of *p followed by an infinite loop that doesn't bother looking at the value of *p at all. In practice, it won't, so it's a question of whether you want to program to the standard, or program to undocumented observed behavior of the implementations you're using. The latter generally works for simple cases, and then you build on the code until you do something complicated enough that it unexpectedly doesn't work.

In practice, on a multi-CPU system that doesn't have coherent memory caches, it could be a very long time before that while loop ever sees a change made from a different CPU, because without memory barriers it might never update its cached view of main memory. But Intel has coherent caches, so most likely you personally won't see any delays long enough to care about. If some poor sucker ever tries to run your code on a more exotic architecture, they may end up having to fix it.

Back to theory, the setup you're describing could cause a crash. Imagine a hypothetical architecture where:

• p points to a non-atomic type, like long long on a typical 32 bit architecture.
• long long on that system has trap representations, for example because it has a padding bit used as a parity check.
• the write to *p is half-complete when the read occurs
• the half-write has updated some of the bits of the value, but has not yet updated the parity bit.

Bang, undefined behavior, you read a trap representation. It may be that Posix forbids certain trap representations that the C standard allows, in which case long long might not be a valid example for the type of *p, but I expect you can find a type for which trap representations are permitted.

If the variable being written to and from can not be updated or read atomically then it is possible for the reader to pick up a corrupt "partially updated" value.

• You can see a partial update (e.g. you may see a long long variable with half of it coming from the new value and the other half coming from the old value).
• You are not guaranteed to see the new value until you use a memory barrier (pthread_mutex_unlock() contains an implicit memory barrier).