gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] shm, volatile, etc.


From: Gary E. Miller
Subject: Re: [gpsd-dev] shm, volatile, etc.
Date: Tue, 5 Nov 2013 12:22:38 -0800

Yo Dave!

On Tue, 05 Nov 2013 11:20:30 -0800
Dave Platt <address@hidden> wrote:

> It may be old news to most, but...
> 
> https://www.kernel.org/doc/Documentation/volatile-considered-harmful.txt
> 
> http://stackoverflow.com/questions/2484980/why-is-volatile-not-considered-useful-in-multithreaded-c-or-c-programming
> 
> If you're *sure* that reordering is never going to be an issue with
> accesses to the variable in question, and that the multithreaded
> access to the variable can't cause anomalous behavior no matter
> how race-condition-y things could ever get under the worst
> possible conditions when the wind is blowing and the moon
> is in the seventh house and Murphy is awake, then maybe "volatile"
> is adequate.

We have looked at the asm generated from gpsd and we have seen
perverse reordering.

We also know that the hardware can reorder in ways the C compiler
has no control over other than a barrier.

> But, based on the discussions cited above (and on the fact that I
> have personally been burned by mis-using "volatile" in just this
> fashion) I really don't think I'll ever depend on it again.

We depend on the barrier, but without some of the volatiles we have seen
problems.

For example, we have seen:
        shmTime->count++;
        [...]
        shmTime->count++;

Optimised without volatile to
        [...]
        shmTime->count += 2;

And more...

> The following was also interesting to me:
> 
> http://www.itworld.com/security/380406/how-your-compiler-may-be-compromising-application-security
> 
> It looks to me as if many (mis)uses of "volatile" would count
> as being "unstable" code, according to the definition in this
> article... and might be at risk for being silently eliminated or
> altered in unpredictable ways by future compilers.

Yeah, can't count on volatile, just another of many attempts to
beat the compiler and hardware into submission.

This is just going to get worse, so I think the chrony socket thing is
the only future proof solution.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

Attachment: signature.asc
Description: PGP signature


reply via email to

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