Safely resetting an outside service that handles requests from multiple threads

I have a program that processes Microsoft Office documents (and other kinds, but primarily Office). I am replacing one purchased product that performs this processing with a new one. This new product consists of a library which is linked in to my code and a Windows service, which performs the actual work. For the most part this new product works better than the old one, but it has a flaw in how it handles some Office documents. Documents that are password-protected can't be processed, and furthermore the third-party product never returns from processing them. For my code this is not a problem; I run the call to the processing on a separate thread with a timeout. After a while I give up. Unfortunately the third-party Windows service does not, and it turns out that it has only a limited number of processing slots. If I send too many documents that don't finish processing, the service stops processing new requests.

I have developed a "hack" to work around this flaw. All requests for processing are sent as lambdas to the class I show below. The requests are multi-threaded at a higher level, so there may be more than one request processing at any time. If a request fails (either by returning false or by throwing an exception), the class stops processing new requests by having threads wait on a manual reset event and waits for threads that are currently processing to finish. Once there are no more running requests for processing, the class calls the code that restarts the service. Once the reset finishes, the class releases any threads waiting on the manual reset event.

There are a number of points on which I am looking for review. First, I have concerns about the correctness of the multi-threaded code. There is one "flaw" that I know about. If any of the passed-in lambdas go into an infinite loop, the reset won't work. This is mitigated in the rest of the code where the lambdas have a "timed executor" wrapper around themselves. But I could have made the timed executor

There's one thing that annoys me about your class and it's the order of the code. You should follow this order:

• Private members

• Constructors

• Properties

• Methods

Your code looks fine, but you could pull the delegates out of your class, since they have their own reason to "live" and are not linked to your class and you should remove the private modifier to your static constructor, this doesn't compile.

StackExchange Code Review Q#43615, answer score: 2