Re: [boost] Cache flushing in the constructors

Subject: Re: [boost] Cache flushing in the constructors
From: Holger Grund (holger.grund_at_[hidden])
Date: 2010-08-04 10:43:38

>> Why would you need to worry about such a thing?
>> That's the responsibility of the compiler/hardware.

> Are you sure the compiler would take care of this?  
Most don't. VC++ uses stores with release semantics for initialization of
volatiles for standard builtin types (char,short,int etc.) on most major
target platforms (and so long the objects are naturally aligned, which isn't
necessarily the case for long long on x86 without further precautions). I
consider that actually an implementation deficiency as volatile shouldn't be
in effect until after initialization is complete -- but that's the way it
is.

The point is that most libraries require the user to avoid races on object
accesses (except for simultaneous const function calls).
 
> I've worked on a number of different CPU's, including the SPARC and the
RS/6000, and I've never seen any special assembly emitted by the compiler
that would do that. I feel like there's still something missing from the
picture.

> You see, normally, entering and exiting a lock takes care of the memory
fencing issues for you, but constructors are naked. By that, I mean there
doesn't appear to be a fence at the end of the constructor, and therefore I
don't see how the current core informs all other cores that a block of
memory has been modified.

If you access the object from another thread of execution without any
syncing you have a race on that object and just saying the behavior is
undefined is common practice in this case. Only if you do need guarantees
for this case you'd have to think about doing something special. If you do
have a "normal" synchronization mechanism it would almost certainly take
care of enforcing memory order.

-hg