And things look good so far!
There are two cases: scope_rt is interrupting a slower thread (including a userspace component), or it is interrupted by a faster thread.
In the first case, the basic atomicity guarantee says that scope_rt will accurately read either the old value or the new value, but never a value between the two.
In the second case, it's possible that scope_rt is interrupted after the first half is read and reads a different second half after it is returned to.
To fix this, I borrow a trick I learned from jmkasunich in stepgen, which is to read the 8 bytes twice; if the values match, then it must be a consistent read.
So far I've let this run for several hours with very fast threads (8us and 32us) and I haven't yet captured an incorrect result. However, the hypothetical window for trouble is very small window--if it's 1 CPU cycle, that's less than 1ns. These threads are loading the system severely enough that the fast thread appears to interrupt the slow thread multiple times (judging from thread times and function tmaxes), so maybe it a test that would routinely hit this <1ns window if it existed. However, my confidence stems much more from my analysis of gcc's generated code and processor datasheets than from a specific test to find a possible 1ns window for incorrect results.
Files currently attached to this page:
doubles-rev2.patch | 14.4kB |
doubletest.comp | 388 bytes |
doubletest.hal | 435 bytes |
(originally posted on the AXIS blog)