L'effetto stop-the-world di .NET Garbage Collector blocca o ritarda l'esecuzione di thread non gestiti e callback del timer?

Question

Ho un'applicazione che deve avere il codice eseguito a intervalli molto precisi. A tale scopo, ho anche bisogno della risoluzione dello scheduler di Windows aumentata a 1 ms tramite timeBeginPeriod.

Per fare ciò, ho una dll C++ nativa che gestisce tutte le cose di importanza temporale tramite richiamate che vengono sollevate da un TimerQueueTimer a un intervallo di 1 ms (tutto il codice nativo).

L'applicazione stessa è un'applicazione .NET (C#, quindi puro CLR). La dll nativa usa il buffering, quindi il codice C# stesso non ha bisogno di essere critico per il tempo, purché ottenga un po 'di tempo di esecuzione ogni 50 ms circa.

Quando il garbage collector colpisce, si fermerebbe o ritarderebbe anche l'esecuzione di qualsiasi richiamo del timer nel mio programma? (In altre parole: la non determinatezza di un programma .NET si estende persino ai frammenti di codice nativo da essa utilizzati?) Non ho trovato una risposta a questa domanda precisa. Un collegamento alla documentazione MSDN sarebbe molto rassicurante.

sto usando .NET 4.0

Answer 1

mia intuizione dice no - il CLR interesserà solo thread gestiti.

1. Il CLR non deve interrompere i thread non gestiti per raccogliere i rifiuti.
2. Il CLR non deve essere a conoscenza di thread non CLR nel processo: violerebbe l'isolamento. Pensa a un server IIS oa un server SQL: entrambi ospitano il CLR, ma non riesco a immaginare il CLR che blocca tutti i thread nel processo ... Anche se le funzioni dell'API WIN32 sono utilizzate dal codice gestito dall'utente (stored-proc/applicazione web) per tentare di manipolare i thread non gestiti nel processo, il codice gestito in hosting non dovrebbe nemmeno disporre delle autorizzazioni di sicurezza necessarie per manipolare i thread non CLR dell'host (su Windows, CLR è "ancora un altro oggetto COM") .

non riesco a trovare una conferma MSDN, ma si può provare a dimostrare che un thread non gestito è in esecuzione durante la raccolta dei rifiuti: avere un filo non gestito costantemente il rintracciamento, e hanno un tracciato GC notification mechanism. Verificare che la traccia del thread gestito continui durante il processo di garbage collection.

(Vale anche la pena notare è che ci sono diversi GC "modes", che si comportano in modo diverso)