Optimization of conditional access to globals: thread-unsafe?

[Darryl Miles]

Dave Korn wrote:
> On 27 October 2007 18:27, Darryl Miles wrote:
>> The "unintended write-access" optimization is a massive headache for
>> developers of multi-threaded code.
> 
>   But it's a boon for the autovectoriser, because it means it can transform
> code with a branch into straight-line code.

Then write to the stack or a register, but not to heap when the 
programmer didn't explicitly permit the compiler to do so because no 
memory targeted lvalue expression was to be executed.

This basic rule about is what a threaded programmer expects of the C 
language, even if there is no written law in C99.


I don't want to stop people using this optimization technique there will 
always be a useful case for it, I just want to be able to turn that one 
off, but keep all other optimizations.


...SNIP...


>> 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.
> 
>   How about attaching the 'volatile' keyword to the variable?

No we are _HAPPY_ to allow "may optimize read access mode" but not happy 
to allow "may optimize read and write access mode" (as per my previous 
description).  Volatile can not differentiate this.  Nor can volatile 
instruct the compiler which method to use to perform the load or store, 
for example a 64bit long long type on i386.

Volatile has its uses but it pretty much a sledgehammer to the problem 
domain.


>> 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.
> 
>   As embedded programmers who have to deal with registers containing
> auto-resetting status bits have known for many years, this is not a safe
> optimisation at all.  We use 'volatile' to suppress it.

It is safe for general programming usage which was the original case. 
See my comment (which you failed to cite) over the use of volatile for 
the situation you describe.  I've already covered this case for you.


>> 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.
> 
>   Huh?  When I tried compiling the test case, it did exactly that.  Hang on,
> I'll check:

We differ slighting on our understanding of volatile.  It does not 
provide exactly what a threaded programmer wants, even thought to you it 
addresses the problem when used with GCC in the cases you have tried.

Your example you cite is coincidental, thats just how GCC generates code.


Darryl