Threading and Design Question

[Guest]

I am designing a multi-threaded application which responds to a
FileSystemWatcher events. Depending on the file created, I need to either
archive the file to a specific directory, or process the file (and maybe in
the future add more functions)

Since I will need to perform two (or more) separate actions on the file
(depending on what it is), what would be the best design scenario? Should I
implement a Producer/Consumer Queue, or some other? I am relatively new to
threading, but have done some extensive reading and playing around (but am
still a new comer to threading).

This application will ultimately run as a windows service, and I would like
to make it extendable.

Thanks In Advance.

 

[Carl Daniel [VC++ MVP]]

I am designing a multi-threaded application which responds to a
FileSystemWatcher events. Depending on the file created, I need to
either archive the file to a specific directory, or process the file
(and maybe in the future add more functions)

Since I will need to perform two (or more) separate actions on the
file (depending on what it is), what would be the best design
scenario? Should I implement a Producer/Consumer Queue, or some
other? I am relatively new to threading, but have done some extensive
reading and playing around (but am still a new comer to threading).

This application will ultimately run as a windows service, and I
would like to make it extendable.

First order solution - don't do anything special at all with regard to
threading (other than appropriate use of locks, etc). The FileSystemWatcher
will already be making calls to your code on a threadpool thread. Unless
you have lengthy operations that need to be serialized (for resource reasons
or performance reasons), there's little to be gained from sticking an
intermediary like a producer/consumer queue between your functionality and
the FSW callback handler.

-cd

 

[leon.friesema]

First order solution - don't do anything special at all with regard to
threading (other than appropriate use of locks, etc). The FileSystemWatcher
will already be making calls to your code on a threadpool thread. Unless
you have lengthy operations that need to be serialized (for resource reasons
or performance reasons), there's little to be gained from sticking an
intermediary like a producer/consumer queue between your functionality and
the FSW callback handler.

-cd

Besides that, two threads both locking the same file: bound to be buggy

Leon

 

[Guest]

I was planning on running the filesystemwatcher on it's own thread. I would
have a "dispatcher" who would register for the created event, and based on
the file it would either launch a new thread to archive the file, or another
thread to process the file.

 

[Carl Daniel [VC++ MVP]]

I was planning on running the filesystemwatcher on it's own thread. I
would
have a "dispatcher" who would register for the created event, and
based on
the file it would either launch a new thread to archive the file, or
another
thread to process the file.

There's no need - FileSystemWatcher already provides all of that behavior
internally. As soon as you enable raising events, the FSW will spin up a an
async call to the Win32 function ReadDirectoryChangesW to actually do the
watching, and callbacks into your code will be made on threadpool threads.

-cd

 

[Jeffrey Tan[MSFT]]

Hi Michael,

I agree with Carl that there is no need to create your own thread for the
processing.

This is because the FileSystemWatcher internally has taken care of the
threading issue and uses a separate ThreadPool thread to fire every event,
so that these events will not block each other. ThreadPool thread is almost
identical to a new thread you create manually, but has better overall
performance because the .Net ThreadPool code maintains the threads lives.
In this model, FileSystemWatcher has acted as the "dispatcher" on behalf of
your code, which is very convenience and transparence to the developers.

If you do not like this ThreadPool model, do you have any special reason to
create new threads for processing?

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Guest]

I didn't realize the FileSystemWatcher utilized multiple threads when firing
events. I don't seem to recall seeing this in the documentation for the class.

Thanks for the clarification Jeffrey and Carl.

 

[Jeffrey Tan[MSFT]]

Hi Michael,

You are welcome.

An easy way to determine if certain event is fired in a second worker
thread is as follow:
1. Set a breakpoint in the main thread code, such as main() method and a
second breakpoint in the event handler code.
2. Press F5 to run the application. When the first breakpoint triggered,
you may open the Debug->Windows->Threads window. In this window, you may
remember your main thread ID.
3. When your second breakpoint hits, you may also open the Threads window
and determine if the current thread ID is the same as the main thread ID.
They should be different for FileSystemWatcher event handler.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.