Updated Course: Developing Windows Concurrent Applications

Thursday, August 18, 2011

During the last couple of months, I have been updating the materials of the Developing Windows Concurrent Applications course. It is now an up-to-date four day ILT with lots of labs, demos, design patterns, and other practical materials to help C++ developers write their next great concurrent application for Windows. The target audience is C++ programmers with 1-2 years of experience writing Windows applications, but who haven’t necessarily seen how to create threads, queue work to the thread pool, synchronize access to shared resources, minimize shared operations, throttle the amount of work, and many other things that are...
no comments

Memory Access Breakpoint for Large Ranges using VirtualProtect

Wednesday, March 23, 2011

Visual Studio has had hardware-assisted memory access breakpoints for quite some time now—they are called data breakpoints and, unfortunately, can be used only for unmanaged code. WinDbg has a similar feature with the ba command, which is more flexible because it can be configured to fire when a memory location is read, not just written. (Of course, WinDbg does not have the managed/unmanaged limitation either, but you still have to exercise caution because managed objects may move in memory every time a garbage collection occurs, which would require you to reconfigure the hardware breakpoints.) This type of breakpoint...
no comments

IsBadXxxPtr Is Really Harmful – Please Don’t Use These Functions

Friday, January 15, 2010

You might have stumbled upon posts like this one that tell you there’s a simple solution for verifying that a memory location is OK for read/write/execution: Just use the “IsBadXxxPtr” family of functions that take a memory address and return a BOOL indicating if you can use the memory. It turns out (and I’m hardly the first to blog about it) that calling these functions causes more problems than it solves, and causes bugs rather than fixes them. Please heed the collective advice and stay away from these APIs. Here are some reasons why: Non-atomicity ...
no comments

Fairness is Highly Overrated

Thursday, December 31, 2009

Fairness with respect to synchronization mechanisms is a highly overrated property. When I talk about concurrency, parallelism, Windows synchronization and similar subjects, I’m often asked whether the specific algorithm, mechanism or feature is fair in some respect. First, let’s define fairness. I’ll use a simplistic yet rigorous definition to define a fair lock. (Other synchronization mechanisms may have fairness defined in a similar fashion.) To begin with, a lock is exactly what you think it is – a mechanism for specifying mutual exclusion. Given N threads that attempt to acquire the lock concurrently, only one thread may enter...
no comments

Windows 7 Taskbar: Tabbed Thumbnails and Previews in Native Code

Wednesday, August 12, 2009

A few months ago, we’ve taken a look at how you can extend your MDI or TDI application with an individual thumbnail and live preview for each tab (or document) that will be displayed in the Windows 7 taskbar. We’ve seen the temporary managed wrapper that makes this possible, and in the final 1.0 release of the Windows API Code Pack there is a more polished managed API that does the same thing. However, in this post I’d like to focus on the underlying details which you will have to deal with if you’re writing your GUI application...
one comment

Managed Synchronization Primitives and Thread Apartment States

Wednesday, August 27, 2008

The managed synchronization mechanisms, including Monitor, WaitHandle.WaitAny, ManualResetEvent, ReaderWriterLock, Thread.Join, GC.WaitForPendingFinalizers and the rest of the family are not just a thin platform adaptation layer on top of the Win32 API. The CLR needs to know exactly which threads are currently waiting for a synchronization mechanisms for a variety of reasons.  To mention two of them: In hosting scenarios, the CLR host might want to limit the ability of application threads to perform synchronization at all (to ensure reliability and control over threads). A waiting thread (in the WaitSleepJoin thread state)...
no comments

More on Converting Native Exceptions to Managed Exceptions

Sunday, August 24, 2008

Shortly after publishing my last post on converting native (C++ or Win32) exceptions to managed exceptions, I realized that some clarifications are in place. Trapping every Win32 exception and indiscriminately translating it to a managed exception is extremely dangerous.  There are various scenarios in which a native exception is thrown to be caught, processed and handled – interfering with this process through a vectored exception handler might result in disastrous consequences. For example, when a managed application attempts to access an object through a null reference, the JIT-ted code causes a Win32 access violation by referencing a...
one comment

Converting Win32 and C++ Exceptions to Managed Exceptions

Wednesday, August 20, 2008

In a layered application consisting of managed upper layers and unmanaged lower implementation layers, you might frequently encounter the need to call unmanaged code, handle any exceptional conditions and reflect them to the upper layers as managed exceptions. This can be done manually, but fortunately as of Windows XP there is an approach that does not require wrapping every unmanaged call in an exception handler.  This approach is vectored exception handling. A vectored exception handler is stackless – it can be attached to an application and get a chance to process any exception before stack-based exception handlers...
no comments

Practical Concurrency Patterns: Spinlock

Sunday, August 10, 2008

Previously in the series we have examined the performance differences between concurrency patterns based on kernel synchronization (critical sections, events, mutexes etc.) and concurrency patterns based on wait-free synchronization (such as the interlocked family of operations).  Kernel synchronization tends to be expensive if locks are frequently acquired and released because of the associated context switches, introducing anti-patterns such as lock convoys.  Wait-free synchronization tends to be expensive if locks are held for a long time because of the spinning which burns CPU without making progress. Oftentimes neither approach is flexible enough to implement a practical scenario, and an intermediate...
one comment

The Case of RegSvr32 and the Haunted DLL

Saturday, June 28, 2008

Last week I've resolved a simple "debugging" case by phone, and figured that it might benefit putting it online.  Here's the approximate outline of the call: Customer: Sasha, we have a COM component registration that is failing because regsvr32 says it can't find the DLL. Myself: Where is it looking for that DLL? Customer: It doesn't matter where it's looking.  We put the component in the System32 directory, but it still complained that it can't find it. Myself: Is it a 64-bit system and you're trying to register a 32-bit component?  You should...
no comments