volatile in struct

[Sergei Organov]

Leon Pollak <leonp at plris.com> writes:
> On Wednesday 18 February 2004 16:20, Sergei Organov wrote:
> > Juergen Zeller <juergen.zeller at argovision.de> writes:
> > [...]
> >
> > > I think I know the meaning of volatile and this is what you discussed.
> >
> > Really? There just been lengthy discussion in 'comp.programming.threads'
> > and 'comp.lang.c++.moderated' newsgroups about what volatile actually means
> > in C/C++ between rather experienced programmers. I had no intention to
> > repeat all that here.
>
> My 2c...:-) I did not read the mentioned news groups discussions but
> according to the names I should assume that the discussion was around the
> possible multi-tasking/threading problems and C++ aspects. About the
> volatile itself, I think, this is rather simple to understand if one can
> look at the assembler code generated by compilers.

The questions being discussed are not what particular compiler does, but
primarily what is guaranteed and what's not according to the C/C++ standards.
Surprisingly enough sometimes some people still care about standards
conformance ;)

> My analysis showed, that in most cases the compiler adds the variable
> address recalculation (if needed) and rereading/writing from/to the
> recalculated address.

In fact I don't see any reason to re-calculate the address and I believe gcc
doesn't recalculate it. It's load/store that is affected by volatile, not the
address itself, unless you declare pointer to be volatile as well:

int volatile *volatile ptr = SOME_ADDRESS;

> I do not mention here all possible problems which can arise in the case of
> multitasking environment, when another task may intervene in the set of
> assembler commands from above...

I think volatile doesn't affect this problem much as it doesn't guarantee
load/store to be atomic. Though it could make things even worse as the
initial OP's problem shows.

-- 
Sergei.