ArangoDB is multithreaded and able to use several CPU-cores at once. Because of that access to common data structures to these threads has to be protected from concurrent access. ArangoDB currently uses mutexes, spinlocks and RW-locks for that. With the ongoing development of the MVCC the number of situations where protected access is needed grows significantly. If locking is done too often the scalability is effectively limited to one core. So this test was done to estimate the costs, and evaluate other solutions – so called lockless programming with atomics. A simple program was written to compare the different techniques. Since ArangoDB should have significantly more reader jobs and threads than writers the test pattern chosen was 49 reader threads and one writer. The test program uses an uint64_t variable, with all threads accessing it. Most use cases will increment the number (“write”), some will only put the loop counter into it (thus slightly different output of the counters, referenced as “set”). All test cases were configured to run one million loops. A concurrent start of all workers is desired. Threads spawned are held back by a C++ 11 construct. It’s the condition_variable so they can be started to do their load testing work at (roughly) the same point in time. The time measured is started from releasing the condition, and all worker threads rejoined the master. Following are the platforms we used for the test: Windows (x64 Windows 8.1 with AMD Phenom II X2) Windows (x64 GRML Small with AMD Phenom II X2) MAC OS X (x64 Intel(R) Core(TM) i3 CPU 540 @3GHz) Linux ARM (Allwinner A20 SOC on Cubie Truck) Linux AMD64 (Intel Core2 Duo CPU E8500 @3.1GHz) Since the idea was to get an overview of the different behaviors on the platforms, varying hardwares were chosen without virtualization. The windows computer was booted with GRML x64 small iso to revalidate whether the significantly different test results were hardware related. Methods tested Here is a list of the implemented algorithms with explanations: Read: reads the current value and increases control counter Write: reads the old value, increases it and writes it back Set: writes a loop counter into the protected variable 0: Unlocked To get a reference to the costs of the locking, the probably race conditions prone flat increment & read was executed. 1: Mutexes The classical way would be to protect the access to the variableaaa