[cpp-threads] Alternatives to SC

[Chris Thomasson]

>> On Wed, Jan 17, 2007 at 12:57:29PM -0800, Chris Thomasson wrote:
>>>
>>> >On Tue, Jan 16, 2007 at 05:05:16PM -0800, Chris Thomasson wrote:
>>> >>From: "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
>>> >>To: "C++ threads standardisation" <cpp-threads at decadentplace.org.uk>
>>> >>Sent: Tuesday, January 16, 2007 9:46 AM
>>> >>Subject: Re: [cpp-threads] Alternatives to SC
>>> >
>>> >Hello, Chris,
[...]
>>> >Out-of-order reads are allowed.  Out-of-order reads can occur
[...]
>>> >
>>> >There are also a number of Intel manuals containing the words
>>> >"Reads can be carried out speculatively and in any order".
>>> >
>>> >So there is no guarantee of #LoadLoad across all x86 implementations,
>>> >even if a number of very popular x86 implementations do in fact provide
>>> >this guarantee.
>>>
>>> Well, does that mean that RCU should have lfence on x86? That would tank 
>>> its
>>> performance, unless you used that "batching" algorithm I mentioned in a
>>> previous post to this group. I hate it when the architecture manual does 
>>> not
>>> "explicitly and clearly " detail its memory model... SPARC documents are
>>> really good in this respect, Intel is really, well, not so good here...
>>
>> Absolutely not.  x86 respects data dependencies.
>

Right, however, isn't this achieved by an "implied" #LoadLoad barrier for
every atomic load?  If the barrier was not implied, then RCU would almost
have to use an explicit barrier call for readers.