Boost logo

Boost :

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2007-03-27 08:39:53


Alexander Terekhov <terekhov_at_[hidden]> writes:

> Anthony Williams wrote:

>> Not according to the intel specs. 25366818.pdf (IA32 software developers
>> manual volume 3A), section 7.7.2:
>
> The thing is that x86 native doesn't have officially defined memory
> model (Itanium mapping may well be stronger than x86 native).
>
> Note that what you quote below was written for testers with scopes on
> "system bus".
>
>>
>> "1. Reads can be carried out speculatively and in any order."
>
> However...
>
> http://www.well.com/~aleks/CompOsPlan9/0005.html
>
> <quote author=an architect at Intel>
>
> The PPro does speculative and out-of-order loads. However,
> it has a mechanism called the "memory order buffer" to ensure
> that the above memory ordering model is not violated. Load
> and store instructions do not get retired until the processor
> can prove there are no memory ordering violations in the actual
> order of execution that was used. Stores do not get sent to
> memory until they are ready to be retired. If the processor
> detects a memory ordering violation, it discards all unretired
> operations (including the offending memory operation) and
> restarts execution at the oldest unretired instruction.
>
> </quote>

Thanks for the links. The "Writes by a single processor are observed in the
same order by all processors" from later in the same spec I quoted above seems
to be key here. This essentially requires that all stores have release
semantics, and that loads have acquire semantics with respect to data written
by a single CPU.

I'm not sure if there is some obscure example where full release/acquire
semantics aren't upheld, but I can't think of one just now.

Anthony

-- 
Anthony Williams
Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk
Registered in England, Company Number 5478976.
Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk