The Old New Thing
Practical development throughout the evolution of Windows.
Latest posts
Corrections to Patterns for using the InitOnce functions
Adam Rosenfield pointed out that it is not possible to fail an asynchronous initialization; if you pass when completing an asynchronous initialization, the function fails with . (Serves me right for writing an article the night before it goes up.) A more correct version is therefore In other words, the pattern is as follows: While I'm here, I may as well answer the exercises. Exercise: Instead of calling with , what happens if the function simply returns without ever completing the init-once? Answer: The structure is left in an asynchronous initialization pending state. This is fine, because the n...
Endorsement: Aaron Margosis's Unintended Consequences of Security Lockdowns talk at TechEd
At TechEd 2011 North America in Atlanta, Aaron Margosis is presenting a talk on Unintended Consequences of Security Lockdowns. I've seen the internal version of his talk and I give it two thumbs up. If you're going to be at TechEd North America, consider adding it to your schedule.
Visual Studio 2005 gives you acquire and release semantics for free on volatile memory access
If you are using Visual Studio 2005 or later, then you don't need the weird function because Visual Studio 2005 and later automatically impose acquire semantics on reads from volatile locations. It also imposes release semantics on writes to volatile locations. In other words, you can replace the old function with the following: This is a good thing because it expresses your intentions more clearly to the compiler. The old method that overloaded forced the compiler to perform the actual compare-and-exchange even though we really didn't care about the operation; we just wanted the side effect of the Acqui...
Back from Las Vegas, and now my clothes smell like cigarette smoke
I actually came back Thursday night, but I've been too lazy to jot down some reactions until now. There are signs on the street directing you to a tram connecting the Monte Carlo hotel with the Bellagio. but once you follow the first sign (that takes you into the casino), there are no more signs telling you how to get to the tram. The tram is a lie. Actually, the tram does exist, but it's not marked. You have to walk through the entire Monte Carlo casino to the Street of Dreams shops, and then past them and up a flight of stairs to the tram station. When you reach the Bellagio, you then have to do the reverse...
Don't forget to include the message queue in your lock hierarchy
In addition to the loader lock, the message queue is another resource that people often forget to incorporate into their lock hierarchy. If your code runs on a UI thread, then it implicitly owns the message queue whenever it is running, because messages cannot be dispatched to a thread until it calls a message-retrieval function such as or . In other words, whenever a thread is not checking for a message, it cannot receive a message. For example, consider the following code: If belongs to another thread, then you have a potential deadlock, because that thread might be waiting for your critical section. ...
Lock-free algorithms: The try/commit/(hand off) model
The last lock-free pattern for this week isn't actually lock-free, but it does run without blocking. The pattern for what I'll call try/commit/(hand off) is more complicated than the other patterns, so I'll start off by describing it in words rather than in code, because the code tends to make things more complicated. First, you take the state variable and chop it up into pieces. You need some bits to be used as a lock and as a work has been handed off flag. And if the work that has been handed off is complicated, you may need some more bits to remember the details of the handoff. A common way of doing this ...
Lock-free algorithms: The opportunistic cache
Suppose profiling reveals that a specific calculation is responsible for a significant portion of your CPU time, and instrumentation says that most of the time, it's just being asked to calculate the same thing over and over. A simple one-level cache would do the trick here. Of course, this isn't thread-safe, because if one thread is pre-empted inside the call to , then another thread will see values for and that do not correspond to each other. One solution would be to put a critical section around this code, but this introduces an artificial bottleneck: If the most recent cached result is , , and if two...
Lock-free algorithms: Update if you can I'm feeling down
A customer was looking for advice on this synchronization problem: We have a small amount of data that we need to share among multiple processes. One way to protect the data is to use a spin lock. However, that has potential for deadlock if the process which holds the spinlock doesn't get a chance to release it. For example, it might be suspended in the debugger, or somebody might decide to use to nuke it. Any suggestions on how we can share this data without exposure to these types of horrible failure modes? I'm thinking of something like a reader takes the lock, fetches the values, and then checks at sta...
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.