global variables and thread safety

[laertius]

I need a little clarification about thread-safety. I understand that some simple operations, like incrementing an index, might not be atomic, but I'm wondering about the case below.

I have a program with two threads. The second thread runs a loop. It's index is copied to a global variable, which the main thread uses to update the UI. Something like this:

for(i = 0; i < max; i ++) {
...
gIndex = i;
...
}

The main thread only reads from gIndex, and never changes it. Is this thread-safe?

Thanks!

[grumpy]

That depends on your definition of "thread-safe", but generally the answer would be "no". changing the value of a variable is not necessarily atomic.

If your second thread was interrupted (or preempted) by the main thread while partway through the (non-atomic) process of executing the assignment "gIndex = i;", and the main thread read the value in gIndex, then the value received by the main thread would be indeterminate. There would be a non-zero probability of that occurring ..... and my definition of "thread-safe" in this example would probably include a zero probability of such an occurrence --- if both threads do their stuff many times, the probability tends to increase with execution time.

[Salem]

Assignment to primitive types such as int are almost always going to be atomic operations. The only place where this isn't likely is inside a packed struct, where the compiler has to manipulate two adjacent storage locations in order to write the int.

> The main thread only reads from gIndex, and never changes it. Is this thread-safe?
You need to make sure it's declared volatile, in order to make sure you keep checking it.

[grumpy]

Unfortunately, Salem, there are commonly used systems where assignment to int is not atomic. Windows operating systems are among them. There are special atomic operations in the win32 API (eg InterlockedExchange() for, effectively, atomically assigning the value of a 32 bit integer) to allow a programmer to cope with this.

Declaring a variable volatile does not make access of it thread safe. With some systems, declaring a variable volatile disables some optimisation features. For example;

   while (control_variable)
    {
        // code that does not change control_variable
    }

can, in principle, be implemented with only one check of control_variable and making it volatile might cause it to be checked every time through the loop. However, the volatile keyword (like some others) is formally a hint to the compiler, and some compilers do choose to ignore that hint --- even if compiling for multithreaded usage.

[laertius]

> The main thread only reads from gIndex, and never changes it. Is this thread-safe?
You need to make sure it's declared volatile, in order to make sure you keep checking it.

I thought that global variables were checked each time in any case, as another subroutine might have accessed it. Is that wrong?

[Salem]

> InterlockedExchange
That's far more than assignment - it assigns a new value and returns the old value.
In other words

old = variable;
variable = new;
return old;

Of course that kind of thing needs protecting from concurrent access problems.

The stated problem was one thread write-only, and another thread read-only.

Are you trying to tell me that
var = value;
can be interrupted?
It's a single machine instruction, either it happens to completion or it hasn't happened at all.

> I thought that global variables were checked each time in any case
Global variables are the same as local variables, except for scope. The access rules do not change.

while ( var != 0 ) {
  // do stuff without ever touching var
}

If the compiler sees that the loop can never modify var, then it's perfectly reasonable to think that the compiler might only read the value once (or maybe never if it can figure out it's value), because there would be no need to.

[anonytmouse]

MSDN: Interlocked Variable Access

Simple reads and writes to properly-aligned 32-bit variables are atomic. In other words, when one thread is updating a 32-bit variable, you will not end up with only one portion of the variable updated; all 32 bits are updated in an atomic fashion. However, access is not guaranteed to be synchronized. If two threads are reading and writing from the same variable, you cannot determine if one thread will perform its read operation before the other performs its write operation.

Simple reads and writes to properly aligned 64-bit variables are atomic on 64-bit Windows. Reads and writes to 64-bit values are not guaranteed to be atomic on 32-bit Windows. Reads and writes to variables of other sizes are not guaranteed to be atomic on any platform.

~~~~

[laertius]

So, is the consensus then that I don't need mutexes here?

[Salem]

I don't think you "need" anything special in this specific case, but it's probably a good idea to get used to using the provided synchronisation functions so you do the right thing when it matters.

[Raven Arkadon]

simple operations can be made atomic by using the lock-prefix btw.
(so write an inline function, that contains the operation (in assebly) with the lock prefix)

[laertius]

I don't think you "need" anything special in this specific case, but it's probably a good idea to get used to using the provided synchronisation functions so you do the right thing when it matters.

Okay. One more question then. As a rule of thumb, I assume you should protect reads as well as writes, since an unprotected read which is not atomic (like a 64-bit var) could be interrupted by a locked write of that same var. Correct?

Thanks everyone for your advice!

[Salem]

Anything which is shared, and not atomic is open for trouble at some point (either reading or writing).

Reading may get half the old value and half the new value.
Writing may be merged with another write happening at the same time.

Your original question was a very specific case.