Re: -fno-tree-cselim not working?

[Ian Lance Taylor <iant at google dot com>]

skaller <skaller@users.sourceforge.net> writes:

> As I understand it volatile is typically used as a 'hint'
> to the compiler that there could be aliases it cannot see.
> This is independent of the use suggesting asynchronous changes
> in a hardware port for example, although the effect is the same.

Not really.  Volatile has a reasonably precise definition: it means
that memory accesses must be done precisely as they are written in the
program.  They may not be coalesced, and they may not be moved.


> So: accesses to any variable read or written
> whilst protected by a lock are ordered with respect
> to any other accesses protected by a lock in any
> other thread, whether or not the variable is aliased
> or volatile.

Yes.

> I'm deducing this from existing practice NOT any standards:
> in this circumstance, volatile is NOT needed.

That is correct: it's not needed if there is a lock, access, unlock
sequence.  In the example which started this brouhaha, there was no
unlock.


> That leaves open several questions. One is: what can
> we say about a write in thread A *prior* to a lock
> being set and released, and a read in thread B
> *after* a lock is set and released, where the read
> is certain to be following the write temporaly,
> for a variable NOT accessed during the exclusion period
> by either thread?

A correct mutex implementation is required to use compiler specific
magic to implement a memory barrier.  In gcc, this magic is implement
via an inline asm.  This memory barrier will impose the natural
ordering requirements.


> And in effect that means ALL variables must be synchronised,
> unless the compiler is exceedingly smart!

No, it means that the implementation of mutex must be magic.


> [BTW I think this sucks, the need to synchronise ALL memory
> on mutexing is far too heavy]

It can not be avoided, for the reasons you describe.

Ian