Missing load barrier at the compiler side for C++ local static objects?
Ian Lance Taylor
Fri Jun 11 16:11:00 GMT 2010
r6144 <firstname.lastname@example.org> 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.
More information about the Gcc-help