The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
Overheard conversation fragment: I'm over here by the slot machines
While on a trip to Las Vegas, I happened to overhear a woman talking on her mobile phone who, from her body language, was clearly trying to meet up with a friend. We were in the casino of one of the major hotels. She said, "I'm over here by the slot machines." Yeah, that narrows it down. I'll be heading to Vegas for the Niney Awards. If I don't see you at the ceremony, I'll meet you by the slot machines.
Lock-free algorithms: The try/commit/(try again) pattern
The singleton constructor pattern and the example we saw some time ago are really special cases of the more general pattern which I'll call try/commit/(try again). I don't know if this pattern has a real name, but that's what I'm calling it for today. The general form of this pattern goes like this: We calculate the desired new value based on the initial value, combining it with other values that vary depending on the operation you want to perform, and then use an to update the shared value, provided the variable hasn't changed from its initial value. If the value did change, then that means another thre...
Holding down the shift key when right-clicking lets you pin things to the Start menu even when you might have been better off not doing so
Holding the shift key when calling up a context menu is a convention for indicating that you want to see additional advanced options which are normally hidden. One of those options is Pin to Start menu. What is this doing as an extended command? The Pin to Start menu command normally appears on the context menu of a program or a shortcut to a program. The Start menu pin list was intended to be a launch point for programs, so if the item you pick isn't actually a program, the Pin to Start menu item will be hidden. Furthermore, only items on the local hard drive will show Pin to Start menu. This avoids ugliness ...
Patterns for using the InitOnce functions
Letting the smart people do the work for you.
Lock-free algorithms: The singleton constructor (answer to exercises)
A few days ago, I asked you to make an existing class multithread-safe. The class caches objects called which are indexed by a 32-bit ID. The cache is implemented as an array that dynamically resizes as more items are added to it. A naïve multithreaded version might use a slim reader-writer lock with shared access on reads, exclusive access on writes, and mixed access on the treacherous "create if it doesn't already exist" path. Let's see. First of all, the function doesn't allocate the memory for the cache until somebody actually tries to look something up. But duh, that's the whole point of the class:...
Lock-free algorithms: The one-time initialization
A special case of the singleton constructor is simply lazy-initializing a bunch of variables. In a single-threaded application you can do something like this: This works fine in a single-threaded program, but if the program is multi-threaded, then two threads might end up trying to lazy-initialize the variables, and there are race conditions which can result in one thread using values before they have been initialized: Observe that if the first thread is pre-empted after the value for is initially set, the second thread will think that everything is initialized and may end up using an uninitialized ...
Lock-free algorithms: Choosing a unique value (solutions)
Last time, I left a warm-up exercise consisting of a code fragment which tries to compute a unique process-wide value. Here it is again: It may be easier to enumerate what the function does right rather than what it does wrong. Um, the words are correctly-spelled. That's about it. Damien was the first to note that the author basically reimplemented . Poorly. As we saw earlier, the algorithm for performing complex calculations with interlocked functions is (capture, compute, compare-exchange, retry). But the above code didn't do any of these things. By failing to capture the values, the code is ...
Lock-free algorithms: The singleton constructor
The first half may be familiar to many (most?) readers, but there's an interesting exercise at the bottom. A very useful pattern for the Interlocked* functions is lock-free lazy initialization via . Yes, that's a really long function name, but it turns out every part of it important. This is a double-check lock, but without the locking. Instead of taking lock when doing the initial construction, we just let it be a free-for-all over who gets to create the object. If five threads all reach this code at the same time, sure, let's create five objects. After everybody creates what they think is the winning obje...
Lock-free algorithms: Choosing a unique value (warm-up)
Here's a snippet of code whose job is to generate a unique number within the process. Here's some reference reading to get yourself in the mood. Caution: It may or may not be useful. Criticize this code fragment.