4 ms·
The most annoying aspect of lock free programming is the amount of 'roll your own' that goes on, and having to inspect this stuff to ensure it's got a chance of
by cesaref 6y ago
The most annoying aspect of lock free programming is the amount of 'roll your own' that goes on, and having to inspect this stuff to ensure it's got a chance of working on the platforms you care about.
I totally get that this technique is inappropriate for many situations where a lock works well enough, but I work in a field (audio) where accidental use of locks and system calls is in general a larger problem than incorrect lock free code.
- jcelerier 6y agoHm, in c++ there are a fair amount of battle-tested, permissively-licensed lockfree containers though I use https://github.com/cameron314/readerwriterqueue https://github.com/cameron314/readerwriterqueue and https://github.com/cameron314/concurrentqueue https://github.com/cameron314/concurrentqueue ; they deliver.
- scott_s 6y agoYes, in addition to the atomics and memory ordering primitives added in the C++11 standard [1], I find the Boost lock-free structures quite reasonable [2]. (Yes, I'm aware some have an automatic aversion to Boost. But it is well-designed and I believe is a header-only library.) [1] https://en.cppreference.com/w/cpp/atomic https://en.cppreference.com/w/cpp/atomic [2] https://www.boost.org/doc/libs/1_74_0/doc/html/lockfree.html https://www.boost.org/doc/libs/1_74_0/doc/html/lockfree.html