Matthew Woehlke <mw_triad@xxxxxxxxxxxxxxxxxxxxx> writes:
> 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.
I think you may consider to remove 'volatile' from your interfaces, and
cast *to* 'volatile' whenever you need volatile access, e.g.:
int foo(int *p)
{
int volatile *vp = p;
*vp = 10;
return *vp;
}
-- Sergei.
