[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Harlan Stenn
Subject: Re: [gpsd-dev] Updated docs on NTP segment management
Date: Wed, 18 Feb 2015 22:33:18 +0000

"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.

I'm sure there are other, better articles.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]