OrderAccess Refactoring

[Erik Österlund]

Hi Paul,

Thank you for clearing things out, it really helps talking to the person 
who originally wrote this code!

It seems to me that this code was written at a time when it was vaguely 
and incorrectly documented both what the hardware and compilers 
guarantee. Must have been a nightmare! I think it's still vague today.

On 09/01/15 23:45, Paul Hohensee wrote
> We understood that volatile semantics wouldn't be enough by themselves
> to implement the semantics we wanted ordering on most platforms, but
> they *are* necessary to prevent compilers (not the hardware though) from
> reordering volatile accesses with respect to each other.  Whether or not
> the volatile keyword prevents non-volatile memory accesses from being
> reordered wrt volatile ones seemed a bit fuzzy in the C++ standard at
> the time (and still does, at least to me), but we figured we could
> handle that in the os_cpu files by checking which compiler was being
> used.  The code that implemented the *hardware* semantics also went into
> the os_cpu file(s).  That's why there's some seemingly silly code there,
> including assembly that executes what amount to nops.

I agree it was and still is very vague which is why different compilers 
interpreted it differently. MSVC is explicit about using acquire release 
for volatiles (wanted) and GCC is explicit about not guaranteeing 
non-volatile w.r.t. volatile. I have not read anything explicit from the 
others so will assume it's unsafe to rely on anything unless we find 
explicit proof it is reliable.

I saw the strange barriers with nops and dummy volatile writes you speak 
of, and intend to change these to normal compiler barriers instead. 
Because the dummy volatile memory accesses don't actually give us the 
guarantees we want for the same reason outlined before (volatile 
semantics not good enough), while also looking a bit strange at the same 
time haha!

> I initially wrote the code in factored form, but changed to the current
> scheme because I found it difficult to see all the code for a single
> platform in one place (I wasn't using an IDE :) ).  In retrospect, an
> unwise decision due to the usual code duplication problems.  Mea culpa. :)

:)

Thank you for the background and useful context Paul!

/Erik