Question

Suppose we have an unmanaged process which loads a managed DLL. Within the DLL there is the need to block some or all threads of the unmanaged application to synchronize concurrent access to some memory.
How can one block those unmanaged threads? I only have the binary of the unmanaged application, so no recompile is possible.

Answer 1

I call to your attention the “Remarks” section of the docs for the SuspendThread API function:

This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. (emphasis mine)

That should suggest to you that what you’re trying is a bad idea. So should the fact that the managed API for suspending threads (Thread.Suspend) turned out to be so problematic that Microsoft actually removed it from the .NET Framework.

The fact is, you cannot safely suspend a thread in the same process as you, without some cooperation from that thread. As one example, you could end up suspending another thread while it’s in the middle of allocating memory, and has a lock on the heap’s control structure. Bam: your thread will deadlock if you try to do anything that allocates memory, which includes JIT-compiling your .NET code. (And the heap lock is just one possible deadlock out of many. And there are race conditions. Just don’t do it.)

As Hans said in the comments above, you cannot implement thread-safe code by suspending threads. You must cooperate with the other thread, by sharing a synchronization object (mutex, slim reader/writer lock, monitor, etc.) and having both sides appropriately signal that synchronization object to say “I’m starting to access this shared resource” and “I’m done”. If one side won’t cooperate, then you cannot have thread safety.

---

If you really must suspend your unmanaged app to update memory locations, and you really can’t get that app’s cooperation, the safest way would probably be to forget about writing an in-process DLL, and instead look to the debugger API. Here’s an article that demos how to use some of the debugger API from .NET.

Make your app a separate process that attaches to your unmanaged app as a debugger (either by attaching after the app is launched, or by starting the app under debug control), and can then control it from outside just as if you were running the unmanaged app under the Visual Studio debugger — suspend, modify memory, resume. Now that you’re in a separate process, you aren’t sharing the heap lock (or most of the other deadlock problems) with the app you’re trying to suspend — so the reasons to avoid SuspendThread largely go away. Since you are writing a debugger (of sorts), now calling SuspendThread is appropriate.

But you’ll still have to deal with the race conditions yourself. Think carefully about what happens if another thread is halfway through writing to your block of memory. (When you resume that thread, it’ll write the other half, corrupting the data you just put there.) And what if another thread is halfway through reading your block of memory — if it’s read the first few bytes, made a decision based on them, and is about to read the next few bytes? If it just read that memory, has a copy of it in its registers, and is about to write it back with changes? Tread carefully.