>>>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> 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