On Fri, 2007-10-26 at 07:58 -0700, Ian Lance Taylor wrote: > skaller <[EMAIL PROTECTED]> 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.
I understand that's the common meaning .. but the semantics aren't specified for ISO C/C++. > > 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. Same thing isn't it? > > > [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. Of course it can be avoided easily if the memory model allowed for local synchronisation sets, so the real problem appears to be that Posix doesn't provide proper synchronisation control. I guess that's why 'volatile' appears attractive: one *might* say that accesses to volatiles are atomic and ordered, without implying anything about other memory (I'm not suggesting that, just commenting that it would provide a way to reduce synchronisation burden). I.e. a volatile variable acts as a kind of 'port' between threads which act like 'processes'. In fact, volatiles mapped onto hardware registers fronting async devices really ARE doing just that. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net
