> I'm
> wary of the fact that in a .Net app, the garbage collector can in
principle
> kick in at any time and suspend all threads whilst it does its work.

>My hope is that if I just create the thread in the usual way
> with _beginthreadex, and just keep it spinning in a loop monitoring the
> Win32 Event, there would be no reason for the GC to take an interest in
that
> thread and suspend it ; but on the other hand, maybe the GC plays safe and
> suspends *all* threads in the application ?

"Steve Terepin" <steve@terepin.freeserve.co.uk> wrote in message
news:e57DVMuzDHA.1576@TK2MSFTNGP11.phx.gbl...
> I'm writing an app that does real time data acquisition, and needs to
> respond to DMA-complete events that get signalled every 10mS
approximately.
> Currently I have some native C++ code that works very nicely, with a
> dedicated 'daemon' thread that waits on a Win32 Event and kicks off the
next
> DMA transfer as soon as the previous one has completed. Now I'd like to
> rework this as a Managed C++ component that I can invoke from C#, but I'm
> wary of the fact that in a .Net app, the garbage collector can in
principle
> kick in at any time and suspend all threads whilst it does its work. What
> would I need to do to ensure that my 'daemon' thread continues to be alive
> all the time, and can respond immediately when the Event it's waiting on
> gets signalled ? If that thread were to be suspended due to GC, it
wouldn't
> get a chance to kick off the next DMA transfer and I'd probably suffer a
> data overrun. My hope is that if I just create the thread in the usual way
> with _beginthreadex, and just keep it spinning in a loop monitoring the
> Win32 Event, there would be no reason for the GC to take an interest in
that
> thread and suspend it ; but on the other hand, maybe the GC plays safe and
> suspends *all* threads in the application ?
>
> Steve.
>
>