[ntp:hackers] [Gpsd-dev] Single-writer/many-reader consistency: Test program written & verified
tglassey at earthlink.net
Wed Mar 30 16:42:45 UTC 2011
On 3/28/2011 7:55 AM, Terje Mathisen wrote:
> tz wrote:
>> On Mon, Mar 28, 2011 at 8:21 AM, Terje Mathisen<terje at tmsw.no> wrote:
>>> Terje Mathisen wrote:
>>> All threads done!
>>> Thread 0 did 1020921970 iterations
>>> Thread 1 did 1939160384 iterations
>>> Thread 2 did 924938960 iterations
>>> Thread 3 did 2002669713 iterations
>>> counter_update = 1047208131, counter_retry = 365502934,
>>> timestamps_inconsistent = 0
>>> I.e. 1e9 write operations, nearly 4e9 reads.
>>> Of the reads 1e9, i.e. about 25% happened in the middle of an update
>>> and one
>>> third of these required a retry due to the counter variable getting
>>> close to
>>> wrapping around.
>> Which architecture, Alpha is apparently the most intersesting one?
How about MIPS as an aside?
> Alpha will work as well, as long as the compiler obeys the rules about
> not moving load/store operations past the barrier.
>> Also, would it be possible to try higher and higher update rates until
>> we detect inconsistency instead of saying 100Hz seems safe.
> That's exactly what I did! The writer managed 13 MHz, the readers
> significantly more.
>> Others have been pointing out that different architectures guarantee
>> different things, so if the architecture you tested on guarantees no
>> (undetected) errors at 400% cpu even without a write barrier the test
>> is not of the algorithm.
>> I'd be curious how fast you could do things on an alpha without a
>> write barrier. Or if you are going to use a write barrier for the
>> architectures, the code that implements it - the long #if ARCH chain.
>> Or will sync_synchronize() be enough?
> As long as the compiler supports it, the sync call will indeed be
> sufficient to make the algorithm safe at any speed.
More information about the hackers