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.
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
The point is that most libraries require the user to avoid races on object accesses (except for simultaneous const function calls). 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