7

I have an application that needs to have code executed at very precise intervals. For that purpose I also need Windows' scheduler resolution increased to 1ms via timeBeginPeriod.

To do that, I have a native C++ dll that handles all the time critical things via callbacks that get raised from a TimerQueueTimer at an interval of 1ms (all native code).

The application itself is a .NET application (C#, so pure CLR). The native dll uses buffering, so the C# code itself does not need to be time critical as long as it gets some execution time every 50 ms or so.

When the garbage collector strikes, would that also halt or delay the execution of any timer callbacks in my program? (In other words: Does the non-deterministicness of a .NET program even spread to native code fragments used by it?) I haven't found an answer to this precise question. A link to the MSDN documentation would be most reassuring.

I'm using .NET 4.0

dialer
  • 4,348
  • 6
  • 33
  • 56
  • What version of .NET are you using? GC changed in 4.5 and it might help you out ([MSDN: Fundamentals of Garbage Collection](http://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx)). – Andy Brown May 20 '13 at 20:52
  • @dialer what has your experience been? Has then been performance issues when running unmanaged threads in a managed environment or not? Thanks :) – BatteryBackupUnit Jun 23 '15 at 07:02

1 Answers1

3

My intuition says no - the CLR will only affect managed threads.

  1. The CLR doesn't need to stop unmanaged threads in order to collect garbage.
  2. The CLR shouldn't be aware to non-CLR threads in the process: it would violate isolation. Think of an IIS server, or an SQL server - both host the CLR, but I can't imagine the CLR freezing all threads in the process... Even if WIN32 API functions are used by the user's managed code (stored-proc / web application) to try and manipulate the unmanaged threads in the process, the managed code being hosted shouldn't even have the security permissions needed to manipulate the host's non-CLR threads (to Windows, the CLR is "yet another COM object").

I can't find an MSDN confirmation, but you can try to prove that an unmanaged thread is running during garbage collection: have an unmanaged thread constantly tracing, and have a GC notification mechanism tracing. See that the managed thread's trace continues during the garbage collection process.

(Also worth noticing is that there are several GC "modes", which behave differently)

M.A. Hanin
  • 8,044
  • 33
  • 51
  • I guess that is correct (I hope so anyway), since the documentation [linked](http://msdn.microsoft.com/en-us/library/ee787088%28v=vs.110%29.aspx) in AndyBrown's comment says that "threads running native code are not affected". However, my timer callbacks run on a thread pool thread, and that thread isn't selected yet between any 2 callbacks. And I'm not sure if all the suspended thread pool threads can be *resumed* during a GC operation (considering there are also managed thread pool threads?) – dialer May 21 '13 at 07:03