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

[Mark Mielke <mark at mark dot mielke dot cc>]

David Miller wrote:
> From: Michael Matz <matz@suse.de>
> Date: Sun, 28 Oct 2007 18:08:23 +0100 (CET)
>   
> > I mean who am I to demand that people write correct code, 
> > I must be insane.
> >     
>
> Correctness is defined by pervasive common usage as much as it
> is by paper standards.
>   
Reading this thread, I find myself confused. GCC is used regularly for 
both multi-threaded and single-threaded code. It is impractical to 
require all variables that may be shared between threads to be declared 
volatile. Worse, I find myself suspecting it may be impossible. Any 
particular library may be used from a multi-threaded context or a 
single-threaded context, with a very common belief that the access can 
be protected by wrapping all accesses to the thread-unsafe resource with 
a mutex. Are some people here really suggesting that all variables 
everywhere be declared volatile?

I remain unconvinced that declaring these shared variables "volatile" is 
correct. Certainly, if the ordering of reads and writes must be 
carefully controlled completely by the programmer, volatile should be 
used. Most uses are not like this. Most uses require only lose ordering. 
The lose ordering is providing by a mutex or other synchronization 
primitive. As any function call might call a synchronization primitive, 
this would mean that any function call should ensure that all scheduled 
reads or writes to shared data before the function is called, be 
performed before the function is called. Similarly, all such data may 
have changed by the time the function returns. Unless the function can 
be proven to have no effect (global optimization analysis? function 
inlining?), this is expected behavior.

Am I stating the obvious? Is this an unreasonable expectation for some 
reason? Do I not understand the issue?

Cheers,
mark

--
Mark Mielke <mark@mielke.cc>