November 17th, 2005

device

Laurel's Prize Tourney

Having missed the chance to get involved with last year's LPT, I've decided I really shouldn't make that mistake again. So...

The next Laurel's Prize Tourney will be held on May 6th in Bergental (western MA). The notion behind the LPT is that Laurels issue "challenges", where each challenge describes something to try doing. Entrants enter the challenges, and get a chance to talk with the Laurels about what they've done. That's the primary focus, IMO, but the at the end the Laurels give prizes (as they choose) to the entrants who they feel have impressed them the most.

There are already a number of challenges that have been issued, and the list continues to grow. I've decided to do two matching challenges: one to reconstruct a Renaissance Dance and one to reconstruct a period game. Yes, I'm throwing down the gauntlet to those of you who have been dithering about trying your hand at reconstruction -- give it a try, and let's talk about the results.

I can provide some general suggestions about how to go about doing it, although obviously I'll have to let you do the details on your own. If you have questions about how to do this, feel free to ask -- this is a topic I'm rather fond of...
device

[PROGRAMMING] Low-Lock Multithreading Techniques

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