[Top][All Lists]

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

Re: [gpsd-dev] SHM refclock improvements

From: Dave Platt
Subject: Re: [gpsd-dev] SHM refclock improvements
Date: Tue, 28 Aug 2012 16:39:40 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120724 Iceowl/1.0b1 Icedove/3.0.11

>>> Yes, and trying to get gcc to not optimize out, and properly fence,
>>> the SHM access is a bitch.
>> I don't know if 'volatile' will help there or not.
> We have tried that, but still run into corner cases.

Yeah... "volatile" is the approach most people think of and try
(me included) but it's not designed as a synchronization primitive
and truly does not work reliably.

I have bloodied my nose on this issue repeatedly over the years...
most recently only a few months ago.

If you want mutual exclusion, you have to use primitives/APIs which
are specifically designed to provide mutual exclusion... and then
hurl rotten asparagus at any architecture/code designer who does not
implement them properly.  Same with atomicity... use primitives and APIs
designed for this purpose, and then harass the compiler/runtime providers
until they do them right.

With the right primitives and APIs, "volatile" is not necessary.  Without
them, "volatile" is not sufficient, and will certainly cause you heartburn
at 4 in the morning some day!

reply via email to

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