r6144 <rainy6144@xxxxxxxxx> writes: > If I'm understanding correctly, to be thread-safe, double-checked > locking in general requires a load barrier between checking the guard > variable and accessing the object. On x86-64 no CPU-level load barrier > is necessary, but shouldn't one be needed at the compiler level? > > Here the guard variable *_ZGBZ1gvE1a.0 is not marked volatile, so can't > the compiler later move the load of a.x before the load of the guard > variable (and redo it if we go the D.2127 path)? This would clearly be > unsafe, as another thread can do the construction after the first load > of a.x and before loading the guard variable, so the current thread > would see object "a" constructed but will be returning a stale > uninitialized copy of a.x. On machines which require a CPU-level load barrier, the compiler generates different code. You're not looking at C code here. You're looking at a dump of the compiler's intermediate representation in a form that, for convenience, looks like C. Not all the information in the IR is dumped out. If the compiler were ever inclined to speculatively load the value before checking the guard, that would be prevented by adding a dependency in the IR. Ian
