Re: [gpsd-dev] SHM refclock improvements

[Harlan Stenn]

Dave Platt writes:
>>>> 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.

In general, I agree with you.

> 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+r
> ace+conditions+with+multiple+threads

The only reason I am considering volatile is that this use-case seems to
be one where we expect to have only 1 writer and 1 (possibly more)
readers.

I know that with multiple writers better primitives and APIs are needed.

I do not have enough current experience to know if we can use volatile
to handle the case of "Did the data change while I was reading it" case.

This is not to say that we should not use better locking primitives/APIs
if we have them.  As others have mentioned, we do our very best to make
sure that ntpd does not make any blocking calls.

It's also looking like we might be able to us pipes for this as well.
Happy to look at that, and it would be even better if this could all be
implemented under Windows.

H