c# - ¿Qué es un "Asín de Asín Asado"?

debugging windbg

Question

Estoy tratando de investigar una falla de software realmente desagradable que posiblemente esté relacionada con una corrupción gestionada del montón (ya que ocurre durante una recolección de basura). Usando WinDbg con el comando (SOS)! Gshandles obtengo algo como

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:

Y tengo curiosidad, ¿cuál es la diferencia entre una manija fija "normal" y una "clavija asíncrona"? ¿Y puedo encontrar cuál de mis identificadores es el "asíncrono"? No pude encontrar ninguna información en la red al respecto y, dado que parece que la aplicación siempre falla cuando este contador es exactamente uno, podría ser relevante para la falla. Pero, de nuevo, podría tratarse de algo interno utilizado durante la recolección de basura.

Answer 1

Las asas ancladas asíncronas están fuertemente correlacionadas con la E / S superpuesta en Windows. Que admite la lectura y escritura asíncronas con ReadFile y WriteFile, utilizando el argumento OVERLAPPED. El controlador del dispositivo almacena el puntero del búfer pasado y lee / escribe directamente desde / en el búfer, completamente de forma asíncrona desde la operación del programa. Los métodos de contenedor administrado son BeginRead y BeginWrite.

Si el búfer se asigna en el montón del GC, entonces debe fijarse hasta que el controlador termine de usar el búfer. Hacer que el GC mueva el búfer mientras el controlador está trabajando en las transferencias de E / S es desastroso, las escrituras producirían basura y las lecturas corromperían el montón del GC, se requiere la fijación para evitar que el búfer se mueva mientras el controlador lo está utilizando.

Los objetos clavados son bastante desagradables, ya que hacen que el recolector de basura tenga dificultades para trabajar alrededor de la roca en la carretera cuando compacta el montón. Un mal necesario aquí, la única manera posible de salir adelante es dejar el búfer inmovilizado por el menor tiempo posible.

Los mangos anclados asíncronos están marcados especialmente para permitir que el CLR libere automáticamente el búfer al finalizar la E / S. Lo más rápido posible, cuando el puerto de finalización de E / S indica la finalización y, por lo tanto, no tiene que esperar a que el código del cliente ejecute la devolución de llamada y libere el búfer. Lo que podría llevar un tiempo cuando hay muchos hilos de threadpool en vuelo. Es una microoptimización que tiende a convertirse en una macro cuando tiene, por ejemplo, un servidor web que maneja decenas de miles de solicitudes de clientes.

Solo se usa para objetos del tipo System.Threading.OverlappedData, una clase interna en mscorlib.dll de la que el CLR tiene un conocimiento especial y es el facsímil administrado para la estructura OVERLAPPED nativa que usan las funciones de la API de Windows.

En pocas palabras, todo lo que realmente sabes es que hay una E / S superpuesta pendiente si ves que el número de identificadores en 1 se bloquea. Tener cualquier código nativo que haga E / S superpuesta con gc asignados a los buffers que no están anclados es una buena manera de destruir el montón. Tienes bastante un montón de asas clavadas por cierto.