什么是“异步固定句柄"? [英] What is an "Async Pinned Handle"?

问题描述

我正在尝试调查一个非常严重的软件崩溃，它可能与托管堆损坏有关(因为它发生在垃圾收集期间).将 WinDbg 与 (SOS) !gchandles 命令一起使用，我得到类似

I'm trying to investigate a really nasty software crash which is possibly related to a managed heap corruption (since it happens during a garbage collection). Using WinDbg with the (SOS) !gchandles command I get something like

0:000> !gchandles
GC Handle Statistics:
Strong Handles: 259
Pinned Handles: 137
Async Pinned Handles: 1
Ref Count Handles: 79
Weak Long Handles: 197
Weak Short Handles: 650
Other Handles: 0
Statistics:

我只是好奇，正常"和正常"之间有什么区别?固定句柄和异步固定"一?我能找到我的哪个句柄是异步"句柄吗?一?我在网上找不到任何关于它的信息，而且由于当这个计数器正好是一个时，应用程序似乎总是崩溃，所以它可能与崩溃有关.但话又说回来，它可能只是垃圾收集期间使用的一些内部东西..

And I'm just curious, what is the difference between a "normal" pinned handle and an "async pinned" one? And can I find which one of my handles is the "async" one? I couldn't find any information on the net about it and since it seems that the application always crashes when this counter is exactly one it might be relevant to the crash. But then again it might just be some internal stuff used during the garbage collection..

推荐答案

异步固定句柄与 Windows 中的重叠 I/O 密切相关.使用 OVERLAPPED 参数支持 ReadFile 和 WriteFile 的异步读写.设备驱动程序存储传递的缓冲区指针并直接从缓冲区读取/写入缓冲区，与程序的操作完全异步.托管包装方法是 BeginRead 和 BeginWrite.

Async pinned handles are strongly correlated with overlapped I/O in Windows. Which supports asynchronous reading and writing with ReadFile and WriteFile, using the OVERLAPPED argument. The device driver stores the passed buffer pointer and directly reads/writes from/to the buffer, entirely asynchronously from the program's operation. The managed wrapper methods are BeginRead and BeginWrite.

如果缓冲区分配在 GC 堆中，那么它需要被固定，直到驱动程序完成使用缓冲区.在驱动程序处理 I/O 传输时让 GC 移动缓冲区 是灾难性的，写入会产生垃圾，读取会破坏 GC 堆，需要固定以防止缓冲区被移动驱动程序正在使用它.

If the buffer is allocated in the GC heap then it needs to be pinned until the driver finishes using the buffer. Having the GC move the buffer while the driver is working on the I/O transfers is disastrous, writes would produce junk and reads would corrupt the GC heap, pinning is required to prevent the buffer from being moved while the driver is using it.

固定对象非常令人不快，当它压缩堆时，它们使垃圾收集器很难在路上的岩石周围工作.这里有一个必要的邪恶，唯一可能的方法是让缓冲区保持尽可能短的时间.

Pinned objects are pretty unpleasant, they give the garbage collector a hard time to work around the rock in the road when it compacts the heap. A necessary evil here, the only possible way to get ahead is to leave the buffer pinned for as short amount of time as possible.

异步固定句柄被特别标记，以允许 CLR 在 I/O 完成时自动取消固定缓冲区.尽快，当 I/O 完成端口发出完成信号时，因此不必等待客户端代码执行回调并取消固定缓冲区.当有很多线程池线程在运行时，这可能需要一段时间.这是一种微观优化，当您拥有处理数万个客户端请求的 Web 服务器时，它往往会变成宏观优化.

Async pinned handles are marked specially to allow the CLR to automatically unpin the buffer on I/O completion. As quickly as possible, when the I/O completion port signals completion and thus not having to wait for the client code to execute the callback and unpin the buffer. Which could take a while when there are lots of threadpool threads in flight. It is a micro-optimization that tends to turn into a macro one when you have, say, a web server that handles tens of thousands of client requests.

它仅用于 System.Threading.OverlappedData 类型的对象，这是 mscorlib.dll 中的一个内部类，CLR 对此具有特殊知识，并且是 Windows api 函数使用的本机 OVERLAPPED 结构的托管传真.

It is only ever used for objects of type System.Threading.OverlappedData, an internal class in mscorlib.dll that the CLR has special knowledge of and is the managed facsimile for the native OVERLAPPED structure that the Windows api functions use.

长话短说，您真正知道的是，如果您在崩溃时看到句柄计数为 1，则有一个重叠的 I/O 待处理.使用未固定的 gc 分配的缓冲区进行重叠 I/O 的任何本机代码确实是破坏堆的好方法.顺便说一句，你有很多固定的句柄.

Long story short, all you really know is that there's an overlapped I/O pending if you see the handle count at 1 when it crashes. Having any native code that does overlapped I/O with gc allocated buffers that are not pinned is otherwise indeed a good way to destroy the heap. You have rather a lot of pinned handles btw.

这篇关于什么是“异步固定句柄"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！