I frequently get asked about the C# compiler’s warning CS0420 about taking byrefs to volatile fields. For example, given a program
Reader/writer locks are commonly used when significantly more time is spent reading shared state than writing it (as is often the case), with the aim of improving scalability. The theoretical scalability wins come because the lock can be acquired in a special read-mode, which permits multiple readers to enter at once. A write-mode is also available which offers typical mutual exclusion with respect to all readers and writers. The idea is simple: if many readers can read simultaneously, the theory goes, concurrency improves.
CAS operations kill scalability.
Type classes, kinds, and higher-order polymorphism represent some of Haskell’s most unique and important contributions to the world of programming languages. They are all related, and began life as type classes in Wadler and Blott’s 1988 paper, How to make ad-hoc polymorphism less ad hoc. Eventually, Jones introduced the (then separate) concept of constructor classes, in his 1993 paper, A system of constructor classes: overloading and implicit higher-order polymorphism. Eventually these two ideas were unified into a beautiful single set of features (namely, type constructors and kinds) in Haskell.
A few months back, while writing my new book, I whipped together a tool to dump information about your processor layout using the GetLogicalProcessorInformation function from C#. You can find the code snippet in Chapter 5, Advanced Threads, of my book. (A developer on the Windows Core OS team, Adam Glass, had also written a similar tool in C++.) I will be posting code to the companion site for my book in the coming weeks, at which point you can easily get your hands on it.
Dan Grossman invited me to deliver a talk as part of the University of Washington’s Computer Science and Engineering Colloquia series. It was recorded and will eventually air on UWTV, but has also been posted online:
The word “architect” means different things to different people in the context of software engineering. And it varies wildly depending on the kind of organization you’re in. An architect at a medium sized IT shop might focus on connecting disparate business systems together at a high level, but without diving down into code. An architect at a startup may be more like a tech lead, checking in code like mad, but also keeping the rest of the team in check. And a software architect at Microsoft can play an even varied number of roles because the company is so large and diversity of projects so great.
It’s been quite some time since I blogged about what I’ve been reading. That’s not because I haven’t been reading – au contraire! – but rather because I’ve been busy doing so. I find these posts interesting for myself, so that I can look back and see where my interests were at a particular point in time. Given the sheer number of additions, I can’t properly rate them like I have in the past. Here are the more interesting ones, those that stick out in my mind:
The October 2008 MSDN Magazine issue just went live with 5 articles on concurrency, plus the editor’s note. Four of the articles are written by members of the Parallel Computing team here at Microsoft, including one by me:
The enumeration pattern in .NET unfortunately implies some overhead that makes it difficult to compete with ordinary for loops. In fact, the difference between