compiler-detected race conditions
May 11th, 2005
featured, projectsMany moons ago, I sent Andrei Alexandrescu some improvements to his Volatile Correctness–How to Have Your Compiler Detect Race Conditions for You concept. Ultimately, Andrei decided not to teach this technique, as overloading the ‘volatile’ keyword is confusing to developers. For posterity, however, this is what I wrote to him, including the source in an attached tarball:
lockptr.h:a small rewrite of your LockingPtr class, using lock and unlock functions as template parameters; locks.h: my extensions, including RWLock encapsulating pthreads’ functionality, a ReadWriteLockable<> template to inherit lockable classes from, and a Lockable<> template to wrap existing single-threaded classes. I left in my comments that summarize usage and provide some simple examples. locks.cpp: pthreads initializers that for some reason don’t exist in the linux pthreads libs. test.cpp/Makefile: a simple test that repeatedly sums and shuffles a vector<int> in multiple threads and with different locking strategies, reporting execution time for each. On my system, the first two testing strategies fail (displayed sum != expectedSum) as expected, since neither of them do any locking (Test2 uses a Lockable<vector<int> > demonstrating that T and Lockable<T> can be used almost identically). Test3 uses writelocks for everything, and Test4 uses readlocks for summation; both run slower, but provide correct results, and Test4 executes about 15% faster than Test3.
To me, this seems like only a modest performance improvement, since the tests sum elements 100 times for every 1 shuffle. Is the pthreads’ implementation of rwlocks among the efficient implementations? I probably just don’t know what amount of improvement to expect from rwlocks as opposed to mutexes.
Stumble it!Comments
Leave a Reply
