I was recently asked by a customer how to guarantee alignment of CLR data on 16-byte boundaries. They needed this capability to interoperate with code that uses SSE vector instructions to manipulate the data (which require 16-byte alignment). The bad news is that there’s no real good way of doing this. That is, there isn’t any “align at N bytes” feature for the CLR in which type layout and stack and heap allocation cooperate. The good news is that you can fake it.
Deadlocks aren’t always because you’ve taken locks in the wrong order.
Raymond just posted a brief entry about lock convoys. While he links to a few other relevant posts, none of them mention the new anti-convoy features that all Windows locks now use. So I thought that I would take the chance to do just that.
I took this past week off so that I could work on my book. Well, I’m happy to report that I’ve been successfully writing like a madman, averaging around 15-20 solid pages per day. I still have a long way to go, but I’m getting more confident with the passing of each day that this book will be… well… a book that I’d actually like to sit down and read.
There’s surprisingly little information out there on Windows keyed events. That’s probably because the feature is hidden inside the OS, not exposed publicly through the Windows SDK, and is used only by a small fraction of kernel- and user-mode OS features. The Windows Internals book makes brief mention of them, but only in passing on page 160. Since keyed events have been revamped markedly for Vista, a quick write up on them felt appropriate. I had the pleasure to chat at length today with the developer who designed and implemented the feature back in Windows XP. (I typically try to get work done during the day, but it seems the whole Microsoft campus was offline, aside from the two of us, due to the 1 or 2 inches of snow we received last evening). I doubt much of this will make it into my book, since knowing it all won’t necessarily help you write better concurrent software.
I was surprised to find out that attempting to acquire an orphaned native “slim” reader/writer lock (SRWL) on the shutdown path hangs on Windows Vista. Unlike orphaned critical section acquisitions during shutdown on Windows – which, in Vista cause the process to terminate immediately, and pre-Vista enjoyed “weakening” to avoid deadlocking at the risk of seeing corrupt state – SRWL’s AcquireSRWLockXXX methods are not shutdown aware.
I just read Dijkstra’s “My recollection of operating system design”, note #1303. He describes issues with the design and implementation of THE operating system, written several years afterward in retrospect. Theme-wise, he focuses on concurrency, resource management and scheduling, fault tolerance, and real-time considerations for fairness. I found the paper to be quite fascinating and easy to read. I enjoyed the theme of concurrency woven throughout, particularly reading about both the failed and successful approaches. The original hand-written note can be found here.
The CLR tried to add support for fibers in Whidbey. This was done in response to SQL Server Yukon hosting the runtime in process, aka SQLCLR. Eventually, mostly due to schedule pressure and a long stress bug tail related to fiber-mode, we threw up our hands and declared it unsupported. Given the choice between fixing mainline stress bugs (which almost exclusively use the unhosted CLR, meaning OS threads) and fixing fiber-related stress bugs, the choice was a fairly straightforward one. This impacts SQL customers that want to run in fiber mode, but there are much fewer of those than those who want to run in thread mode.
People often ask whether they should use EventWaitHandle objects or the Monitor.Wait, Pulse, and PulseAll methods for synchronization. There is no simple answer to this question; although, as with most software problems, it can be summarized as: It depends.
The meat of this article is in section II, where a set of best practices are listed. If you’re not interested in the up-front background and high level direction—or you’ve heard it all before—I suggest skipping ahead right to it.