Re: [gpsd-dev] Updated docs on NTP segment management

[Harlan Stenn]

"Gary E. Miller" writes:
> > > Sadly read order can not be fixed on many architectures, like x86.  
> > > So X and Y may have been flushed by the cache to main RAM, but not
> > > the data it is guarding. 
> > 
> > I'm not a wizard on this area.  I have worked with people who are.
> > When I asked one of them, he gave me that recipe.  When I asked about
> > cache flushes and such, he said that x86 hardware does the right
> > thing.
> 
> Not been my experience, and the world is not all x86.  Getting it
> right is very architecture specific, and that is what libc is for.
> Dn't reinvent the hwheel (badly).
> 
> > I think the actual code needs volatiles in the right places (so the
> > compiler will do the right thing) and a few memory barriers on some
> > architectures.
> 
> gpsd has seen that volatiles do not work as expected (you'd have to
> check the archives) and memory barriers are essential.  Sadly 
> memory barriers play havoc with multi core systems while cores wait 
> for everything to flush and refill.

We relied on volatile to do the right thing in similar places for NTP
and I got a report from an ARM(?) user who said that while volatile was
great for x86, it was insufficient for platforms like ARM(?) where
parallel threads really mean parallel threads.  Apparently a *lot* of
(Java?)  code that ran fine on x86 broke there.

It's a read-barrier thing, as I recall.

 
http://stackoverflow.com/questions/1787450/how-do-i-understand-read-memory-barriers-and-volatile

 
http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming

 http://www.rdrop.com/users/paulmck/scalability/paper/whymb.2010.06.07c.pdf

 http://blog.coverity.com/2014/03/26/reordering-optimizations/#.VOUS-TpNnaA

I'm sure there are other, better articles.

H