[ntp:hackers] [Gpsd-dev] Single-writer/many-reader consistency: Test program written & verified

Terje Mathisen terje at tmsw.no
Mon Mar 28 20:07:32 UTC 2011


Dave Hart wrote:
> On Mon, Mar 28, 2011 at 19:21 UTC, Gary E. Miller<gem at rellim.com>  wrote:
>> On Mon, 28 Mar 2011, Terje Mathisen wrote:
>>
>>> Dave Hart&  I have banged quite a bit against the (fixed) version of the test
>>> program, and the conclusion is quite nice:
>>
>> Good result, but missing the most crucial detail on the tests: what CPU
>> architecture?
>>
>> As we have seen x86 has the strongest rules on reordering. Â What about on
>> another CPU, like ARM with weaker rules?
>
> There's some porting work to be done.  So far just x86 using threads
> on Windows.  Still, I did include a dual-proc Pentium II 400MHz, which
> predates Intel's strictest guarantees.  Below are the hour-long runs I
> did.  Note the output is misleading, it still says 10 seconds when it
> was in fact 3600.  Also despite the mention of debug\test_shm the
> binary was fully optimized, including link-time code generation and
> non-debug C runtime.  The source file is test-shm.c, the test_shm.exe
> name is a result of quirk in how I set up the build here.

[various x86 test targets snipped]

>
> Nowhere near as interesting as Alpha or ARM, granted, and hard to

I agree.

> interpret without the source, which will have to wait for Terje.

I still haven't made the program runtime configurable, i.e. command line 
parameters for things like test time duration and number of threads, but 
the current source code is located here:

http://norloff.org/ntp/shm-test/

This version actually uses 32 extra bytes per 32-byte timestamp record, 
making the total 64 bytes.

This means that each timestamp uses a separate cache line, meaning that 
with proper alignment (which is currently still missing) the writer can 
generate a new timestamp record without forcing all the readers to give 
up their read access to the previous record. It did increase the maximum 
read/write frequency by quite a bit.

I would love to see a *ix port, if nobody volunteers I'll use a VMware 
64-bit Ubuntu to see if I can figure out the relevant Linux calls.

Terje
-- 
- <Terje at tmsw.no>
"almost all programming can be viewed as an exercise in caching"


More information about the hackers mailing list