David Miller wrote:
From: Michael Matz <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
