Re: [boost] Cache flushing in the constructors

Subject: Re: [boost] Cache flushing in the constructors
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-08-04 10:36:37

Sid Sacek wrote:
>
> >> Why would you need to worry about such a thing?
> >> That's the responsibility of the compiler/hardware.
> >> Rob Stewart
>
> Are you sure the compiler would take care of this?

I wrote "compiler/hardware" purposely.

> 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.

That's the job of cache coherency logic in the hardware.  When you access the object in another thread running on another CPU, the hardware must arrange for that other CPU to see the new state of the memory occupied by the new object, at some point.  That also means that the other CPU may not *yet* see the new object's state.  When one thread creates an object for another to use, it is your responsibility to use fences or locks to force the consuming thread to see what the producing thread did.

Normally, however, an object isn't created by one thread and handed off to another, so fences are rarely warranted in a constructor.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.