This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++0x Memory model and gcc


Michael Matz <matz@suse.de> writes:

> On Mon, 17 May 2010, Ian Lance Taylor wrote:
>
>> >> Since the atomic operations are being built into the compiler, the 
>> >> intent is to eventually optimize and inline them for speed... and in 
>> >> the best case, simply result in a load or store. That's further work 
>> >> of course, but these options are laying some of the groundwork.
>> >
>> > Are you and the other proponents of that memory model seriously 
>> > proposing it as an alternative to explicit locking via atomic builtins 
>> > (that map to some form of atomic instructions)?
>> 
>> I'm not sure what you mean here.  Do you an alternative way to
>> implement the C++0x proposed standard?
>
> I actually see no way to implement the proposed memory model on common 
> hardware, except by emitting locked instructions and memory barriers for 
> all memory accesses to potentially shared (and hence all non-stack) data.  
> And even then it only works on a subset of types, namely those for this 
> the hardware provides such instructions with the associated guarantees.

I'm sure the C++ standards committee would like to hear a case for why
the proposal is unusable.  The standard has not yet been voted out.

As far as I understand the proposal, though, your statement turns out
not to be the case.  Those locked instructions and memory barries are
only required for loads and stores to atomic types, not to all types.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]