This is the mail archive of the 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?

David Miller wrote:
From: Michael Matz <>
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?


Mark Mielke <>

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