Windows 7, undigested red meat, and a delicate sensibility

Remember those "compare and contrast" assignments from high school? "Compare and contrast George Washington's position on privateering with King George's position on high seas piracy" (35 marks)." Fun, weren't they? - and especially so if you didn't really have a clear understanding of either position.

In that same spirit of deeply confused inquiry, compare and contrast these two excerpts from other people's blogs.

The first is from zdnet's own Mary Jane Foley's Windows 7 coverage: under the headline: Windows 7 to scale to 256 processors:

Russinovich said that Microsoft has managed to break the dispatcher lock in Windows, a task that had stumped even the father of the Windows NT operating system, David Cutler. When Cutler designed Windows for the server, systems beyond 32-way seemed far, far away, Russinovich said.

On more massively multiprocessor systems, Windows threads spin while waiting for the dispatcher lock. Once Cutler had been moved to work on Microsoft Red Dog (Windows Azure), another kernel developer, Arun Kishan, looked at this problem with a set of fresh eyes and found a solution, Russinovich said. By adding another state, so threads aren't just running or waiting, but can be "pre-waiting," as well, Windows will be better suited to running parallel, multi-threaded applications running across manycore systems, Russinovich said.

Russinovich noted with the dispatcher-lock roadblock removed, a second set of locks became the new focus for folks working on the Windows kernel. The PFN database inside Windows, which contains information on all of the physical memory in the system, was becoming another scalability bottleneck when trying to get Windows to handle multithreaded apps on massively multicore machines. With Windows 7 and Windows Server 2008 R2 (Windows 7 Server), Microsoft again broke this lock down into finer grain locks, Russinovich said.

The second is from a blog entry by Bryan Cantrill headed "Concurrency's Shysters"

There also seemed to be no end of concurrency hucksters and shysters, each eager to peddle their own quack cure for the miasma. Of these, the one that stuck in my craw was the two-level scheduling model, whereby many user-level threads are multiplexed on fewer kernel-level (schedulable) entities. (To paraphrase what has been oft said of little-known computer architectures, you haven't heard of it for a reason.) The rationale for the model -- that it allowed for cheaper synchronization and lightweight thread creation -- seemed to me at the time to be long on assertions and short on data. So working with my undergraduate advisor, I developed a project to explore this model both quantitatively and dynamically, work that I undertook in the first half of my senior year. And early on in that work, it became clear that -- in part due to intractable attributes of the model -- the two-level thread scheduling model was delivering deeply suboptimal performance...

Several months after starting the investigation, I came to interview for a job at Sun with Jeff, and he (naturally) asked me to describe my undergraduate work. I wanted to be careful here: Sun was the major proponent of the two-level model, and while I felt that I had the hard data to assert that the model was essentially garbage, I also didn't want to make a potential employer unnecessarily upset. So I stepped gingerly: "As you may know," I began, "the two-level threading model is very... intricate." "Intricate?!" Jeff exclaimed, "I'd say it's completely busted!" (That moment may have been the moment that I decided to come work with Jeff and for Sun: the fact that an engineer could speak so honestly spoke volumes for both the engineer and the company. And despite Sun's faults, this engineering integrity remains at Sun's core to this day -- and remains a draw to so many of us who have stayed here through the ups and downs.) With that, the dam had burst: Jeff and I proceeded to gush about how flawed we each thought the model to be -- and how dogmatic its presentation. So paradoxically, I ended up getting a job at Sun in part by telling them that their technology was unsound!

Back at school, I completed my thesis. Like much undergraduate work, it's terribly crude in retrospect -- but I stand behind its fundamental conclusion that the unintended consequences of the two-level scheduling model make it essentially impossible to achieve optimal performance. Upon arriving at Sun, I developed an early proof-of-concept of the (much simpler) single-level model. Roger Faulkner did the significant work of productizing this as an alternative threading model in Solaris 8 -- and he eliminated the two-level scheduling model entirely in Solaris 9, thus ending the ill-begotten experiment of the two-level scheduling model somewhere shy of its tenth birthday.

Now, a word of warning. the implied conclusion here is obvious, but quite possibly wrong. To my knowledge, Microsoft hasn't published enough information for outsiders to know for sure, and I don't have the background to impute the missing pieces - but at least until Microsoft publishes a clearer description of their not-a-lock lock, I'm going to believe that they're following their usual pattern: re-inventing technologies Unix has left behind.