[cpp-threads] Web site updated

[Peter Dimov]

Paul E. McKenney wrote:
> On Tue, Feb 13, 2007 at 09:56:06PM +0200, Peter Dimov wrote:
>> Paul E. McKenney wrote:
>>
>>>> Similarly, I'd expect in
>>>>
>>>> a.store_raw( 5 );
>>>> a.store_raw( 6 );
>>>>
>>>> the first store to be optimized out.
>>>
>>> MMIO accesses, anyone?
>>
>> This is what volatile is for.
>
> To the extent that it is defined...

Well. We routinely get arguments about how undefined volatile is, but nobody 
seems to have any problems with it in practice. Compiler writers and users 
tend to agree on its basic effects (extensions to provide acquire/release 
constraints notwithstanding.) There are some complications in C++ having to 
do with the lvalue to rvalue conversion, but no real showstoppers. :-)

>>> Hardware timing analysis (especially if there is a short loop
>>> between the two)?
>>
>> (1) A short loop composed of ordinary operations can be reordered
>> across either store;
>
> Even though it is a special store_raw()?

What is "special store_raw"? The difference between store_raw (or _relaxed) 
and store_release is that store_relaxed is missing the reordering 
constraint. The only sensible reason to omit a reordering constraint is to 
enable reordering. So

// ordinary ops
store_relaxed

can be transformed to

// ordinary ops 1/2
store_relaxed
// ordinary ops 2/2

(by the compiler or the hardware) but

// ordinary ops
store_release

cannot.

> This would prohibit implementations of reference counts or locks based on 
> store_raw().

I believe that reference counts do work when the increment is _relaxed. 
Unlocking a mutex is a _release operation, so I'm not sure how store_raw is 
relevant there. But I may be missing something.