I played around with lock-free algorithms a year ago and came away with a rather dim view of
them. It's easy to write a provably correct lock-free queue when you assume infinite memory
(something that most papers seem to do). It's a lot messier when you need to ensure the safe
disposal of list items when you're done with them.
You mention he's using an atomic CAS. Does he explicitly solve CAS's ABBA problem? It's
easily solved if you assume infinite memory of course. If you're on a real-world system, if
you're not careful, you can easily open yourself up to situations where CAS assures you that a
value is unchanged when in reality you lost out a long time ago and the ring has just wrapped.
(yes, it's not hard to solve if you're watching for it, but always having to worry about this
sort of subtlety is what makes working lock-free such a pain)
After realizing they were anything but maintainable, I chucked lock-free algorithms on my
shelf of stuff that is academically fascinating but unrealistic for the real world. Should I
take them back down and re-examine them?
> When the callback for queue empty happens, the code to operate on the queue is switched to
use the lock-free synchronization code. When the quaject's queue-not-empty callback is
invoked, the quajects switch back to the synchronization-free code.
Whoa... that ran shivers down my spine. What an outrageously cool idea.