[cpp-threads] Slightly revised memory model proposal (D2300)

[Nick Maclaren]

"Paul E. McKenney" <paulmck at linux.vnet.ibm.com> wrote:
>
> Eek!!!  In my mind, permitting stores to "flicker" into existence is
> a cure that is far, far worse than any disease I can imagine.  Such
> "flickering" would break quite a bit of code.

I am not sure that it would break much that isn't already broken,
but I am dead sure that it would make it impossible for even an
expert to work out whether or not such code was broken!

I agree.  That's curing chilblains by infecting the patient with
malaria.  Please, no!

> How about instead -slightly- weakening the ordering requirements,
> so that ordered reads can disagree about the order of unordered stores
> to different variables?

Fine.  But let's see a proper, semi-mathematical specification.
I can see that being viable, and I can see it being ambiguous.

Personally, I think that there is a straight choice between making
the abstract machine serial order a requirement, using only the
actual store dependencies, and not specifying ANY dependency
between different locations.

The last approach would be that store_relaxed would be totally
unordered until there was a store-release; each receiving thread
would see stores from each transmitting thread in a determined
order, but that order might be different for every pair of
transmitting and receiving threads.

Yes, it's a hard line, but it's simple.  store_relaxed would now
mean "I am setting up data for a later atomic export - look at it
before it is exported at your peril."  But even that wouldn't allow
flicker between a SINGLE pair of threads!


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679