“When I was but a wee computer science student at New Mexico Tech, a graduate student in OS handed me an inch-thick print-out and told me that if I was really interested in operating systems, I had to read this. It was something about a completely lock-free operating system optimized using run-time code generation, written from scratch in assembly running on a homemade two-CPU SMP with a two-word compare-and-swap instruction – you know, nothing fancy. The print-out I was holding was Alexia (formerly Henry) Massalin’s PhD thesis, Synthesis: An Efficient Implementation of Fundamental Operating Systems Services (html version here). Dutifully, I read the entire 158 pages. At the end, I realized that I understood not a word of it, right up to and including the cartoon of a koala saying ‘QUA!’ at the end. Okay, I exaggerate – lock-free algorithms had been a hobby of mine for the previous few months – but the main point I came away with was that there was a lot of cool stuff in operating systems that I had yet to learn.”
Synthesis: An Efficient Implementation of Fundamental OS Services
Submitted by renox 2008-03-14 OS News 6 Comments
It seems to me like this design results in the duplication of the same code several times. I’m not sure how this is an advantage over a more traditional function-pointer based object system (in which you can still often pull the same runtime specialization tricks through vptr jamming).
I have done some coding myself using inline assembler and the CMPXCHG instruction, since the Microsoft C++ x86 intrinsic does not seem to directly expose the actual compare-and-swap power of CMPXCHG. The Google query (( _InterlockedCompareExchange CMPXCHG )) finds as the 8th hit an “HP OpenVMS systems” article explaining “But there are also new builtins with names and signatures matching those provided by Intel’s IA64 compiler, _InterlockedCompareExchange*. Instead of returning a status value, these return the value fetched. If it matches the comparison value passed in, then the new value was stored; otherwise the store did not take place”
So in other words with JUST the x86 to worry about, the ZF already says if the CMPXCHG worked or not. Evidently InterlockedCompareExchange() was designed to be compatible with other architectures, perhaps the Alpha works that way, I don’t know. But it’s a plausible explanation of why if you call InterlockedCompareExchange() primitive rather than just using the CMPXCHG directly, you then need the additional comparison to know if it worked or not – those other architectures might not set a flag, and Wintel in the days of NT wanted to be compatible with all of them.
Or if there is some other explanation, it would be worth the embarrassment to know the real story !