M
Mike
I am noticing a severe spike in CPU usage during peak times when
FileSystemWatcher is in use. I have taken some precautions to guard
against this phenomenon.
First, I implemented a thread-safe queue. I post the events that are
received from the watcher to the queue. I spawn a thread to process
the event(s) that have been received.
Next, I am considering how to regulate the execution of the thread
itself. During peak hours the event queue can get really busy. The
thread has a tendency to utilize the CPU near 100%.
I have read about two probably reliefs to this tendency. First is a
timer. I dislike using a timer because when it fires, if I'm not ready
to process the next event, then the callbacks stack up on one another.
This might be alleviated using .NET Monitor to block until it is clear
for the next cycle to proceed.
Second is simply to sleep. It would be a simple matter to sleep
following processing of each event.
I am experimenting with both ideas. Can anyone offer any other wisdom?
Thanks.
FileSystemWatcher is in use. I have taken some precautions to guard
against this phenomenon.
First, I implemented a thread-safe queue. I post the events that are
received from the watcher to the queue. I spawn a thread to process
the event(s) that have been received.
Next, I am considering how to regulate the execution of the thread
itself. During peak hours the event queue can get really busy. The
thread has a tendency to utilize the CPU near 100%.
I have read about two probably reliefs to this tendency. First is a
timer. I dislike using a timer because when it fires, if I'm not ready
to process the next event, then the callbacks stack up on one another.
This might be alleviated using .NET Monitor to block until it is clear
for the next cycle to proceed.
Second is simply to sleep. It would be a simple matter to sleep
following processing of each event.
I am experimenting with both ideas. Can anyone offer any other wisdom?
Thanks.