Re: [gpsd-dev] SHM refclock improvements

[Dave Platt]

>>> 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!

https://www.securecoding.cert.org/confluence/display/cplusplus/CON01-CPP.+Do+not+use+volatile+as+a+synchronization+primitive

https://www.securecoding.cert.org/confluence/display/seccode/CON00-C.+Avoid+race+conditions+with+multiple+threads