r6.0.0:Known Issues

liblfds

• The release note doesn't mention the new() function API changes (bug 4)
• liblfds does not in fact support IA64. I had thought there was a compiler environment bug of some kind which affected this build, but it turns out to be a mistake on my part; IA64 does not in fact support contigious double-word compare-and-swap. (bug 8)
• The library does not use memory barriers correctly. The main upshot of this is that the queue can be corrupted; a missing barrier means that the queue can be misled about its state during enqueuing or dequeuing and as such attempt to perform the wrong action (both of those operations operate in different ways depending on the current internal state of the queue). How likely this is to happen is not clear; the window is a few instructions in length (e.g. short), it can only happen when multiple cores are using one queue, it is more likely the more busy the queue is (both in terms of number of cores using the queue and the frequency of enqueuing and dequeuing), but on my test systems, which include a 16 core, 2 NUMA node machine, I have yet to see errors even with all cores busy-using the queue (which may mean the tests are no good, at least for this problem - they certainly detected enough errors during development and testing). (bug 16)
• When built as a DLL, the abstraction API is not exported nor is the rinbuffer query function. The absence of the abstraction API do not prevent end-user use (these functions are never called directly by the user) but their absence does prevent the test programme from being able to build and run against the DLL build of liblfds. The absence of the ringbuffer query function is an end-user visible bug, since users should be able to call this function. (bug 18)
• With more modern GCC versions (the issue was found with 4.6.2) the shared object build on x86 runs out of registers when trying to assemble the in-line assembly code for contigious double-word compare-and-swap. Release builds still compile. (bug 20)
• Inlining is broken, due to misunderstanding how the keyword works. (bug 24)

test

• The test and benchmark program offers an iteration argument, for running tests multiple times; in fact, this is bugged, and will crash on the second iteration. The problem is use of static variables in the tests, which don't get reset to 0 and so cause memory exceptions (it worked on x64!). (bug 6)
• In the slist test (/src/test/test_slist.c) there is a missing check for NULL on line 444, which is part of the core of the traverser thread, a test thread which simply constantly loops over a list. This causes race condition which can lead to tests 4, 5 and 12 throwing an assert. (bug 10)
• The freelist popping test is bugged. A variable, count, is declared as unsigned int when in fact it needs to be atom_t. The consequence is that on 64-bit platforms where unsigned int is 32 bit and pointers are 64 bit, the freelist test will report missing elements. (bug 12)
• The freelist pushing test is bugged. The test allocates (one million / number cores) freelist elements per thread. Now, with integer division, on a (for example) 24 core machine, this gives (1,000,000 / 24) = 41,666 elements per thread. However, after the test has run, there is a check that there are in *exactly* 1,000,000 elements now present in the destination freelist. This fails, because 41,666 * 24 = 999,984. The error seen is that the freelist is missing elements. (bug 14)
• The SList and Stack 'tests' are not proper tests but merely workloads. (bug 22)
• On Linux, the thread starter doesn't set affinity. This is bad because the scheduler may well since the threads access the same memory want to put them on the same core; which defeats testing! (bug 26)