C# 阻止非托管代码的线程
假设我们有一个加载托管 DLL 的非托管进程。在 DLL 内，需要阻止非托管应用程序的部分或全部线程以同步对某些内存的并发访问。 如何阻止那些非托管线程？我只有非托管应用程序的二进制文件，因此无法重新编译。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我提请您注意 SuspendThread API函数：
这应该表明您正在尝试的是一个坏主意。用于挂起线程的托管 API (Thread .Suspend）问题非常严重，以至于 Microsoft 实际上将其从 .NET Framework 中删除了。
事实上，如果没有线程的配合，您就无法安全地挂起与您相同的进程中的线程。举一个例子，当另一个线程正在分配内存时，您可能最终会挂起另一个线程，并且该线程在堆的控制结构上有一个锁。 Bam：如果您尝试执行任何分配内存的操作（包括 JIT 编译您的 .NET 代码），您的线程将会死锁。 （堆锁只是众多可能死锁中的一个。并且存在竞争条件。只是不要这样做。）
正如 Hans 在上面的评论中所说，您无法通过挂起线程来实现线程安全代码。您必须与另一个线程合作，通过共享同步对象（互斥锁、薄读/写锁、监视器等）并让双方适当地向该同步对象发出信号以表示“我开始访问此共享资源”并且“我受够了”。如果一方不合作，那么就无法实现线程安全。
如果您确实必须暂停非托管应用程序来更新内存位置，并且您确实无法获得该应用程序的配合，那么最安全的方法可能是忘记编写进程内 DLL，而是查看到调试器 API。 这里一篇文章演示了如何使用 .NET 中的一些调试器 API。
让您的应用程序成为一个单独的进程，作为调试器附加到非托管应用程序（通过在应用程序启动后附加，或者通过在调试控制下启动应用程序），然后可以从外部控制它，就像您运行非托管应用程序一样Visual Studio 调试器下的应用程序——暂停、修改内存、恢复。现在您处于一个单独的进程中，您不再与您尝试挂起的应用程序共享堆锁（或大多数其他死锁问题）——因此避免 SuspendThread 的理由基本上消失了。由于您正在编写（某种）调试器，因此现在调用 SuspendThread 是合适的。
但您仍然需要自己处理竞争条件。仔细考虑如果另一个线程正在写入您的内存块，会发生什么情况。 （当您恢复该线程时，它会写入另一半，从而破坏您刚刚放在那里的数据。）如果另一个线程正在读取您的内存块，那么会发生什么情况 - 如果它读取了前几个字节，则做出了决定基于它们，并且即将读取接下来的几个字节？如果它只是读取该内存，在其寄存器中拥有它的副本，并且准备将其写回并进行更改？ 谨慎行事。
I call to your attention the "Remarks" section of the docs for the SuspendThread API function:
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.