Menu
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
706
So, the garbage collector is nothing but a background thread that runs continuously. Checks for unused managed objects clean those objects and reclaims the memory. Now, it is important to note that the garbage collector cleans and reclaims unused managed objects only. It does not clean unmanaged objects.
NET's garbage collector manages the allocation and release of memory for your application. Each time you create a new object, the common language runtime allocates memory for the object from the managed heap.
Automatic memory management is made possible by Garbage Collection in . NET Framework. When a class object is created at runtime, certain memory space is allocated to it in the heap memory.
You can force garbage collection either to all the three generations or to a specific generation using the GC. Collect() method. The GC. Collect() method is overloaded -- you can call it without any parameters or even by passing the generation number you would like to the garbage collector to collect.
My intuition says no - the CLR will only affect managed threads.
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)
159
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
