Re: C Programmer Needed

In article <1137904328.846003.224230@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, websnarf@xxxxxxxxx writes:
> CTips wrote:
> > 3. sharing+rendevous/barrier: consider an array that is used for double
> > buffering messages between two threads. Every time we start processing a
> > message, we need to use the new values in the array. One way of telling
> > the compiler this is to mark the array as volatile. However, this is too
> > heavy weight. It inhibits a lot of optimizations in the compiler.

It needn't do anything. The C standard makes no guarantees at all
for the "volatile" type-qualifier. It says that the implementation
must follow the semantics of the abstract machine when accessing a
volatile-qualified object, but then makes "access" implementation-

In particular, there is *no guarantee whatsoever* that the implementa-
tion will provide a memory barrier at a volatile access. I haven't
surveyed C implementations, but consider the case of Java; prior to
the new Java memory-access semantics that arrived with Java 5 (IIRC),
volatility did not require a memory barrier, and so for example the
double-checked locking pattern was invalid.[1]

Scott Meyers and Andrei Alexandrescu wrote a two-part article for DDJ
explaining why DCL isn't (portably) reliable in C++ for the same

> Usually you need a token or flag of some sort to allow this to work.
> So in fact, all you need is to be able to declare some parts of a
> struct volatile. Can't you do this today?

That's entirely implementation-dependent. In particular, even if
the compiler generates loads for every read of a volatile-qualified
object and stores for every write to such an object, it may well not
generate memory barriers to ensure its cache coherence.

1. See eg

2. and (subscription
required for full text).

Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx

Ten or ten thousand, does it much signify, Helen, how we
date fantasmal events, London or Troy? -- Basil Bunting