[PROGRAMMING] Low-Lock Multithreading Techniques

[jducoeur]

I had always assumed that MSDN Magazine was yet another PR mouthpiece for Microsoft, and never paid it much heed. But the October issue, which was being given away at the Software Development conference, turns out to be pretty interesting -- much more technical depth than I'd expected, and less shilling for the company. (Amusingly, the PR mouthpiece appears to be the nominally independent magazine "Code", which I found more or less worthless due to its slavishly breathless devotion to All Things Microsoft.)

Anyway, there's a fascinating article in there on low-lock memory techniques -- more on the subject of how to write multithreaded apps without resorting to heavyweight locks. Without getting into exhaustive detail, the article focuses on exactly why low-lock techniques are difficult, and examines why you have to deeply understand the memory model you're working in to be able to use these techniques safely. It contrasts several memory models relevant to .NET programming (the ECMA model, the x86 model and the .NET 2.0 model) and what you can and can't do in each, and then examines several of the major techniques one can legitimately use to reduce locking.

(Precis of the main point: in a modern multiprocessor, you have to assume that your threads are running on separate cores, each of which has its own memory cache. Each of these cores is permitted, within certain parameters, to rearrange the reads and writes of that memory. This means that many apparently-safe code paths can wind up failing unpredictably, due to processors doing things in unexpected order. So safe low-lock programming requires understanding the legal rearrangements in detail, and analyzing the problem quite carefully in that light.)

Very neat article, and worthwhile reading for all hardcore programming geeks. While the article is understandably focused on the .NET world, a good 80% of the content should be applicable to any multiprocessor environment -- it's mainly concerned with explaining the gotchas you have to watch for, and how to think about the problem...

Comments

[metahacker.livejournal.com]

How odd. I read this, and thought, "Huh. Might be interesting to know." But then I realized I didn't have a way to get MSDN with zero effort on my part, and really didn't need that piece of knowledge anyway.

Today, someone misfiled a copy of MSDN in my mailbox.

Unfortunately, it's the Dec. issue, but I'm looking it over carefully anyway before passing it on, just on the previous recommendation.

[jducoeur]

Note that the above link is actually a pointer to the article in question. It appears that more or less all of the content of MSDN Magazine is available for free on the Web -- presumably they view it as a sensible loss leader, to promote better programming. (And reduce their support costs...)

[metahacker.livejournal.com]

Link?

Oh, I completely missed it. I dislike the fact that this stylesheet doesn't underline links, but not quite enough to learn how to change it...