Re: Heads-up: volatile and C++

[Paul Koning <pkoning at equallogic dot com>]

>>>>> "Robert" == Robert Dewar <dewar@adacore.com> writes:

 Robert> Ken Raeburn wrote:
 >> That's what I thought.  So, unless the compiler (or language spec)
 >> is going to become thread-aware, any data to be shared across
 >> threads needs to be declared volatile, even if some other
 >> mechanism (like a mutex) is in use to do some synchronization.
 >> Which means performance would be poor for any such data.

 Robert> The use of shared variables without synchronization is rare
 Robert> in any case in most code.

You mean "without explicit synchronization" via mutexes or the like?

It seems that the classic circular buffer communication mechanisms
have been forgotten by many, but they still work quite well and
require no mutexes or the like.  All that is required is sufficiently
ordered memory accesses. 

 >> Which takes me back to: I think the compiler needs to be
 >> thread-aware.  "Enhancing" the meaning of volatile, with the
 >> attendant performance issues, still doesn't seem adequate to allow
 >> for multithreaded programming, unless it's used *everywhere*, and
 >> performance shoots through the floor....

 Robert> I don't see the point here, volatile is exactly intended to
 Robert> deal with this situation

At this point I'm sufficiently confused about what the precise current
definition and proposal are that I don't know if the following is
correct today, will be correct under the proposal, neither, or both.
Anyway...

I'm using circular buffers to communicate between threads.  I drop
data into the buffer and move the "in" pointer; the consumer compares
the pointers, reads data from the buffer, and advances the "out"
pointer.  The current code has the pointers declared as volatile, buf
the buffer data area is not (and I wouldn't want it to be -- that
seems to be a performance issue).

So this relies on volatile references acting as barriers to the
movement of non-volatile references.  In a coherent memory system (or
single CPU platform) that's sufficient; in a non-coherent or weakly
enough ordered system I would add asm("sync") or the like.

       paul