The Kernel Hacker's Bookshelf: Synthesis: An Efficient Implementation of Fundamental Operating Systems Services

> 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?

My personal opinion is that lock-free algorithms are not a good generic synchronization
technique, and are definitely very very complex and difficult to understand.  However, in
certain specific cases, lock-free can be simple, elegant, and a huge performance advantage
over traditional approaches.  It's much like RCU - you wouldn't want to use RCU for every
synchronization problem, but when it comes to highly-shared read-mostly data in the hot path
(e.g., the dcache), it's worth the trouble.

It's kind of like my advice on choosing a file system: Use ext3 unless it's not
fast/big/whatever enough for you, in which case use XFS.  My recommendation is use locks
unless they have too much contention/complexity/whatever, in which case look into lock-free.

> > 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.

I know... The whole damn dissertation is like that.