This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimization of conditional access to globals: thread-unsafe?



Comments inline below vvvvv



Tomash Brechko wrote:
Consider this piece of code:

extern int v;
void
f(int set_v)
{
if (set_v)
v = 1;
}


    f:
            pushl   %ebp
            movl    %esp, %ebp
            cmpl    $0, 8(%ebp)
            movl    $1, %eax
            cmove   v, %eax        ; load (maybe)
            movl    %eax, v        ; store (always)
            popl    %ebp
            ret

Note the last unconditional store to v.  Now, if some thread would
modify v between our load and store (acquiring the mutex first), then
we will overwrite the new value with the old one (and would do that in
a thread-unsafe manner, not acquiring the mutex).

So, do the calls to f(0) require the mutex, or it's a GCC bug?

The "unintended write-access" optimization is a massive headache for developers of multi-threaded code.



The problem here is the mandatory write access to a memory location for which the as-written code path does not indicate a write memory access should occur.


This is a tricky one, optimizations which have the effect of causing an "unintended write access to some resource" when the code path does not intend this to happen crosses a line IMHO.

I think that GCC should understand where that line is and have a compile time parameter to configure if that line maybe crossed. Its a matter for debate as to what the default should be and/or -O6 should allow that line to be crossed, but having no mechanism to control it is the real bummer.

Even if the interpretation offered of the C language standards specification says the line maybe be crossed, from a practical point of view this is one aspect of optimization that a developer would want to have complete control over.

So much control that I would also like to see a pair of __attribute__((optimization_hint_keywords)) attached to the variable declaration to provide fine grain control. Such a solution to the problem would keep everybody happy.


Here are some pieces from C99:

...SNIP...
Sec 3.1 par 4: NOTE 3 Expressions that are not evaluated do not access
               objects.

Hmm... on this point there can be a problem. There are 2 major types of access read from memory (load) and write to memory (store). It is very possible to end up performing an optimistic read; only to throw away the value contained due to a compare/jump. This is usually considered a safe optimization.


But reading the statement above as-is and in the context of this problem might make some believe this "optimistic read" optimization is breaking the rules.


Maybe in GCC there should be C99 adherence levels :


strict mode: Where this C99 clause is adhered to, but this is much like compiling code without optimization, like when debugging. Since during debugging you always want nice clear per line / per expression separation so you can walk through execution with a debugger.

may optimize read access mode: This is the normal case for optimization, where you might interleave a 'compare reg with immediate' and a 'load from memory', then perform a 'conditional branch' that ends up at code that never uses the value loaded from memory. The only rare case this is a problem is where a read from special memory, but volatile in GCC exists for that or you could move all accesses to that memory away from regular C language syntax and into a function call.

may optimize read and write access mode: This is the problem case you are seeing. Same as the mode above but also permits the unintended write access, but only to write back the same value as before (based on the compiler's thread naive perception of execution at least!).



So, could someone explain me why this GCC optimization is valid, and,
if so, where lies the boundary below which I may safely assume GCC
won't try to store to objects that aren't stored to explicitly during
particular execution path?  Or maybe the named bug report is valid
after all?

As has been pointed out by others there is no specification on what happens between threads.



Your route out of this problem is to write your own implementation of:


atomic_int_set(int *ptr, int value);

Which always uses an atomic single instruction store. Which is thread-safe with respect to ensuring that no other concurrent read or write to that location will ever see a corrupted value. Where a corrupted value in this case would be some value other than "the previous value of 'v'" and "the value of '1'" you are setting, also that once a concurrent access with "the value of '1'" is first obversed, it will not be possible to observe the previous value on a subsequent read (the value doesn't flap about once it changes, it changes for good).

if (set_v)
  atomic_int_set(&v, 1);



By doing the above you are programatically dictating the method of thread-safety in 2 directions.

One direction in terms of something that is agreeable with a compiler and something it can't optimize/change. By using a basic function call invocation to an external symbol the compiler has no room to be able to think about optimization. Since the compiler does not know the side effects that calling this external symbol may have. So it can't reorder this operation either, so it occurred exactly at the moment your code says it should.

The other direction is in terms of the target CPU assembler instructions and architecture. The implementation of your atomic_int_set() will be fixed by expressing the operation directly in assembler (to be sure it always will use a single instruction move register to memory).


It would also be true that you should also have a method for reading the current value of 'v' in an atomic way.


This may also mean you have to create a function:

extern int atomic_int_get(int *);

For the purpose of obtaining the current value. Yes you have to apply the same care when reading the value as you do with setting it.



NB Marking the variable 'volatile' does not mean anything useful in the situation you are in. The exact meaning of what 'volatile' is can be a problem between compilers, but in the case of GCC it can stop the re-ordering and the caching of value in register aspect of your entire problem. But it will never enforce the method used to perform the load/store, not will it (at this time) stop the unintended write-access. Although in the case of an aligned integer of natural bitwidth it is somewhat difficult for the compiler to do the wrong thing on most architectures, as the most efficient instruction is the atomic load/store between register and memory.


Darryl



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]