"When is it a good idea to start using more than one thread?"

Usually about 9:30AM on a Monday morning, after my second cup of coffee...

Seriously...many people find this a very difficult decision.

Consider a current requirement that requires the multiplication of two (numberic) textboxes in response to a button click...

The "obvious" answer is that this is simple enough, do it inline...

Now three months later the requirement changes to take the two values submit it to a back end system (via a WebService) which may take 10+ seconds to perform the calculations and respond (we are even neglecting timeout issues).

The "obvious" answer is that this should be done on a thread.

The result may very well be a significant amount of rework to both the UI and "Business" components including architectural changes.

Since we are a small consulting firm, re-usability and flexability are factors which directly translate to our ability to provide a reliable and maintainable solution at a competitive price point.

For us, it has proven to be effective to create a UI framework that is completely decoupled form ALL of the logic. At the simplest level, the UI event handlers contain exactly 1 method call to the logic facade. The UI registers to logic facade events to update controls.

For WinForms our UI framework tests if an Invoke is required (ie the event has been fired on a different thread than the control) and transparently performs the required operation.

For ASP.Net (non-AJAX) the event handlers in the UI aggregate the data until the final event is fired, which releases a mutex on the page processing.

Other environments have similar types of constructs. This means that the logic is (almost) totally "environmentally agnostic". This has also proven to be a very effective implementation for a TDD (Test Driven Development) environment. As soon as the "logic facade" is defined, the UI (with a test logic simulator) and the Logic (with a UnitTest or other harness) can be developed completely independantly. It also allows for simple testing of conditions that may be very difficult to induce when using the entire application.

This approach is NOT for everyone, but when the development costs have been amortized over dozens of projects, the benefits really start to appear and pay of rapidly.

Getting back to the original question (no, I didnt forget it), the usage of threads (typically via the ThreadPool and WorkItems) becomes a very localized decision, where individual circumstances can be individually assessed.

What we have been finding more and more common (especially with things like the inclusion of Microsoft Windows Workflow into the application) is that the decisions regarding threading are influenced by the static hardware configuration (e.g. number of processors/cores) as well as dynamic issues (e.g. Procesor loading, IO loading, Network bandwidth).

While the thread pool does to some adaptation regarding the number of concurrent worker threads, it can not compensate for the differences between a laptop/desktop with a relatively slow single IDE drive compared to a server with high speed SCSI arrays or a SAN....

 

 

 

---

TheCPUWizard is a trademark of Dynamic Concepts Development Corp. Please visit us at www.dynconcepts.com

I use multiple threads when there are tasks that can be done in parallel to other tasks and the tasks may take a long time complete.

Threads running in a multi-cpu or multi-core environment work well because the load can be spread out among cpu's or cores.

In a single-cpu, single-core configuration, although threads help prevent the UI from 'going stupid', they do slow down the overall time it takes to complete the task because of the cpu context switches. In this environment if numerous threads are I/O bound (disk especially) the UI may still go stupid because the main UI thread can't get enough of a time slice to update the window. Still, a minor tradeoff compared to looking bad vs the competition or frustrating the user.

If I'm writing a UI app I'll use threads for things like background printing where I don't want the UI held up on a synchronous call. For web services, I'll use the async calls provided by the proxy when available. Thankfully, Silverlight is all async oriented.

If I'm writing some sort of server application that takes incoming connections then I'll use threads to help my app scale better. In this situation, the trick comes when trying to figure out how many threads to use and when to start queuing.

In some apps I might be making lots of requests rather than trying to respond to requests (read data from multiple sources). Also can be a good use of threads.

I have also used threads for background monitoring the availability of a network resources or the living/dead status of other tasks.

One last nice thing about threads is that you can raise or lower their priority if you need to. I've only had to do this once.

Threads do pose problems (deadlocks, race conditions and code complexity) so life is not all good with threads, but I find them useful more often than not.

I think it should be from today because computers are now multi-core :).
When working with Winform application, it's hard for me to think of not using multi-threading because I want my application to be very responsive.

In other hand, if I got a several tasks that can perform independently, then the first thing come into my mind is multi-threading. If I got a number of similar tasks to do (that mean they can be done is parallel) then again, it's multi-threading.

1. Keep a process responsive. GUI as well as comms endpoints.

2. Keep a processor busy. Delegate resource (eg Network and IO) access.

3. Keep multiple processors busy. Processors aren't getting faster, but horsepower can still be bought.

4. Improve coding of cooperating tasks. Make it right and make it fast.

Having read some books/articles/blogs from the wizards and playing around a bit for myself: According to Amdahl's law (Gustafson's law when it comes to Multi-Threading) the gain in 'speedup' depends very much (if not only) on how much of the code is still left as 'serial part' after some kind of 'parallel' redesign. Maybe the game is not worth the candle! If you cannot make use of 'threadpools' (.NET framework and/or the CCR (--> MS Robotics Studio)) or other things like the background worker thread and you have to deal with the synchronization primitives (event, semaphore, mutex, spin wait, critical section, interlock, etc.) on your own, and you end up with data race, deadlock, livelock, lock contention and ---worse--- it only works with attached debugger (aaargh, timing problem! ;-) but not for your release build, then you need some good friends out there...

So when to use one more or even more threads?

- If your 'problem' naturally fits into parallel design, and you find community approved and stable parallel algorithms out there, and

- If you have enough time to consider Multi-Threading right at the beginning of the design phase, and

- If the hardware supports more than one (hardware) thread, and

- If the (class) libraries in use are branded 'thread-safe' (for that special kind of use!), and

- If your compiler suite is worth the money (special kind of thread support? OpenMP support? MPI support? 'parallel for (...) {...}' code language feature? ;-), and

- If the CPUs are wasting resources (probably some of them are being bored), and

- If you can test with a lot of different equipment (Multi-Core, Hyperthreading, pure 64Bit EPIC microcode design): cache coherence issues, different instruction set architecture and/or different memory models may have unwanted/unsuspected effects!

Conclusion: Don't deal with low-level Thread-APIs! ;-)

-Klaus