Question

I have several thread synchronization questions involving a simple .NET C# design. I have ideas on how to do the synchronization, but I would like to pass the ideas by other programmers that have more .Net experience than myself (almost anyone).

The design:

This is test control software.

There is a GUI in one thread (GUI thread) that has start, stop gracefully, abort, pause and resume buttons. In addition, it displays the results of each test. The results are updated as the test is run.

Then there is a thread that runs the test. It is kept separate from the GUI so the GUI will remain responsive. The test is simple with no real time considerations, things that blow up, etc.

Then there is a data class with the results of the tests.

I was thinking of making the data class a global static (so there will only be one) and shared between the two threads protected by means of a Mutex. The run class would get the Mutex, then update the data, release the Mutex and then call a delegate method that updates the GUI. Is there are better way of doing this?

The abort, stop gracefully, pause, and resume are more difficult. The run test method is chugging along in its own thread when suddenly the user wants to change things. The stop gracefully, pause and resume could be handled with flags in the data class that are checked by the run thread periodically. Those flags could be set by the GUI thread (using the Mutex again of course). And abort… How about killing the run thread and then calling a method that puts all the test equipment in a known state? Is there a better way of doing this?

Answer 1

I agree that your question could be more specific, but I’ll take a shot.

You’re generally correct about using Flags to signal your worker thread when it should pause/resume/stop gracefully (Auto and ManualResetEvent may also come in handy). You are also correct that Abort is going to be your biggest problem. Since you are presumably calling into code not your own (or at least, code that isn’t aware it’s being called on a worker thread), you have no way of signaling the worker thread that it should abort when it’s in the middle of a test. Using Thread.Abort is “considered harmful” and could certainly leave the process in a strange state. You could try using an AppDomain to sandbox the execution of the test code, which would allow you to simply teardown the entire AppDomain in the event of an abort. This would be a good approach anyway, since the code you’re testing could be modifying global state, thereby effecting future test runs in the same process.

Also, since it sounds like you’re writing some kind of testing UI/framework, have you considered using an existing package like NUnit or the test capabilities built into Visual Studio?