Andrew Haley wrote:
I suppse we have to ask the OP why he's using volatile.
Ok, I guess I should answer that. It's part of a typedef that is essentially 'typedef volatile long atom_t', i.e. the type that is passed to atomicAdd, atomicSwap, etc functions (which are of course written with inline assembler using 'lock' - the memory barriers are handled). Also because atomicRead is a no-op to simply read the value, since this is safe. So I'm expecting 'volatile' to a: discourage compilers from doing stupid reordering to the code, like say putting the read before a call to atomicXyz, and b: force a re-read from memory (in case some other thread is changing the value) rather than using a cached value.
Now I'm wondering if maybe I should just drop the volatile, but I'm not sure I trust doing that...? Michael Eager's post makes it sound like I am in exactly the few cases where use of 'volatile' is appropriate.
Oh, and did I mention I'm actually implementing lightweight mutexes? :-) I can't use pthread mutexes; this code is supposed to build on Windows and Solaris also (Solaris has pthread mutexes but not the FAST/ADAPTIVE type AFAIK).
-- Matthew HIPPOS feel unacknowledged. HIPPOS get angry. > PRAISE HIPPOS HIPPOS seem somewhat placated.
