2013-05-20 8 views
6

Ich habe eine Anwendung, die Code in sehr genauen Intervallen ausgeführt werden muss. Zu diesem Zweck brauche ich auch Windows 'Scheduler Auflösung auf 1ms über timeBeginPeriod erhöht.Stoppt oder stoppt der Stop-The-World-Effekt von .NET Garbage Collector die Ausführung von nicht verwalteten Threads und Timer-Callbacks?

Um dies zu tun, habe ich eine native C++ - DLL, die alle zeitkritischen Dinge über Callbacks behandelt, die von einem TimerQueueTimer in einem Intervall von 1ms ausgelöst werden (alle nativen Code).

Die Anwendung selbst ist eine .NET-Anwendung (C#, also reine CLR). Die native DLL verwendet Pufferung, so dass der C# -Code selbst nicht zeitkritisch sein muss, solange er alle 50 ms Ausführungszeit benötigt.

Wenn der Garbage Collector anschlägt, würde dies auch die Ausführung von Timer Callbacks in meinem Programm anhalten oder verzögern? (Mit anderen Worten: Breitet sich die Nicht-Deterministik eines .NET-Programms sogar auf native Codefragmente aus, die von ihm verwendet werden?) Ich habe auf diese präzise Frage keine Antwort gefunden. Ein Link zur MSDN-Dokumentation wäre sehr beruhigend.

ich .NET 4.0

+0

Welche Version von .NET verwenden Sie? GC wurde in Version 4.5 geändert und es kann Ihnen helfen (MSDN: Grundlagen der Garbage Collection) (http://msdn.microsoft.com/en-us/library/ee787088 (v = vs.110) .aspx)). –

+0

@dialer Was ist deine Erfahrung gewesen? Gab es bei der Ausführung von nicht verwalteten Threads in einer verwalteten Umgebung Leistungsprobleme oder nicht? Danke :) – BatteryBackupUnit

Antwort

3

Meine Intuition sagt nein - die CLR nur verwaltete Threads beeinflussen.

  1. Die CLR muss nicht verwaltete Threads stoppen, um Müll zu sammeln.
  2. Die CLR sollte im Prozess nicht auf Nicht-CLR-Threads achten: Dies würde die Isolation verletzen. Stellen Sie sich einen IIS-Server oder einen SQL-Server vor - beide hosten die CLR, aber ich kann mir nicht vorstellen, dass die CLR alle Threads im Prozess einfriert ... Selbst wenn die WIN32-API-Funktionen vom verwalteten Code des Benutzers verwendet werden (stored-proc/Webanwendung), um die nicht verwalteten Threads im Prozess zu versuchen und zu manipulieren, sollte der gehostete Code nicht die erforderlichen Sicherheitsberechtigungen haben, um die Nicht-CLR-Threads des Hosts zu bearbeiten (nach Windows ist die CLR "ein weiteres COM-Objekt") .

Ich kann keine MSDN Bestätigung finden, aber Sie können zu beweisen versuchen, dass ein nicht verwalteter Thread während der Garbage Collection ausgeführt wird: haben ein nicht verwalteter Thread ständig verfolgt und haben eine GC notification mechanism Verfolgung. Beachten Sie, dass die Ablaufverfolgung des verwalteten Threads während des Speicherbereinigungsprozesses fortgesetzt wird.

(auch beachtenswert ist, dass es GC "modes" mehrere sind, die sich anders verhalten)

+0

Ich denke, das ist richtig (ich hoffe es trotzdem), seit der Dokumentation [verlinkt] (http://msdn.microsoft.com/en-us/library/ee787088%28v=vs.110%29.aspx) in AndyBrowns Kommentar sagt, dass "Threads mit nativem Code nicht betroffen sind". Meine Timer-Callbacks werden jedoch in einem Threadpool-Thread ausgeführt und dieser Thread ist zwischen zwei Callbacks noch nicht ausgewählt. Und ich bin mir nicht sicher, ob alle gesperrten Thread-Pool-Threads * während einer GC-Operation * wieder aufgenommen werden können (unter Berücksichtigung, dass es auch verwaltete Thread-Pool-Threads gibt?) – dialer