Re: [gpsd-users] gpsd and shared memory

[Roger Oberholtzer]

________________________________________
From: Gary E. Miller address@hidden
Sent: Monday, October 05, 2015 8:57 PM
To: Roger Oberholtzer
Cc: address@hidden

> Oversimplyfying just a bit, a barrier just pauses the current CPU until all 
> pending cache reads and writes have finished.

Hmm.. Learned something new today. I am familiar with volatiles. In the context 
of hardware registers and such. And I would have been tempted to use them here 
as well. I have read up a bit on barriers and think I have then straight. At 
least in your use. Odd that I don't have a man page on my system.

And the bookends ensure the read segment is coherent.

So why am I wanting to use the shared memory interface? I would probably need 
to implement something similar to your shared memory segment access as the 
socket reader would be in a different thread than the user of the data. So 
ensuring coherent access of the data structure I would maintain could require 
similar actions.

The socket is working in the time domain - new data arrives at the rate of the 
GPS, in Hz. I want to make decisions about the data in the distance domain 
(e.g., each meter). I still maintain that the shared memory makes this easier. 
And since gpsd is already making the segment, using it must be more efficient 
than adding another similar data structure that must also be maintained.

So, to reiterate a few of my questions:

1. If the shared memory segment changes during the read, does the read return 
that there was nothing to read?

2. If the data is the same as before, does the read return it again?

My answer from looking at the code is that the answer to both is yes. How did I 
score?


Roger Oberholtzer

RST Systems

Office: +46 (0)10-615 6020
Mobile: +46 (0)70-815 1696
address@hidden
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se