Helge Bahmann wrote:
On Tuesday 02 August 2011 19:28:08 Phil Endecott wrote:
The thing that I believe is missing is tests. Do you have any thoughts about that?
Well, I have a few simple tests for atomicity only, they are hand-built and I am working to push them into the boost build system.
I don't know how useful the tests are though -- while on a true SMP platform (ppc and x86 being available to me) they manage to fail quite realibly if I intentionally break something (like removing "lock" prefixes, or replacing stwcx. with an unconditional store), but it takes ages (if it works at all) to produce test failures on non-SMP (all threads to the same CPU).
I recall someone once increasing the kernel's scheduling frequency to make this work better. On Linux, I think this means changing HZ and recompiling the kernel. Perhaps there is some trick that could be used to force the kernel to reschedule more frequently without going to those lengths. Or maybe it is easier on some other platform. Even so, scheduling only happens between instructions, not between memory accesses. When a single instruction does more than one memory access (i.e. a typical CISC instruction), process scheduling will never occur between the two memory accesses. I think it is probably safe to test only on multi-core systems, and to assume that if code works on them then it will also work on single-core systems.
I have not yet looked into writing something for memory ordering tests, but arguably that's both even more important and more difficult to reproduce failures.
I agree. I have no idea where to start on that. Hopefully there is someone else reading with a clue....
The other aspect that I want to provide is compile-time test for API completeness. I suspect there are a few small things missing still.
Yes. Also, it would be very easy to make a copy&paste error and find that something is doing an atomic add instead of an atomic and. Or that it was only changing the least-significant byte, or something. So some basic "does everything compile (and assemble)?" and "do I get the same answer as with non-atomics?" tests would be good. Also, I think it would be useful to verify at compile time that the expected atomic code is being used, and not the fallback (this is something that has bitten me). In fact, it might be worth putting in a #warning for the fallback implementation that the user has to explicitly disable. Regards, Phil.