Threading or not?

[Orf]

Hello.
Some time ago I felt in love with multithreading techniques, and I structured my project using a lot of threads - too many, I think.
At the moment, I'm trying to avoid threading... for instance, at the moment I'm working with MIDI and my choice was to use windows messaging instead of a MidiInCallback procedure (running in its own thread).
I ask for your opinion: when is it wise to use threading? When it isn't?
Thanks and best regards.

[Andreas Masur]

Well...multithreaded is a complex topic and is still often being misused by many programmers probably for some reasons like: "Hey, I am using a lot of threads, that is cool" etc. - you get my point I guess...

Nevertheless, writing multithreaded applications or even designing multithreaded applications is more than that. You can nearly write every program having multiple threads, however, many times this is nearly unneccessary. One common example when you would consider multiple threads is for example if you have a GUI application and need to do a lengthy operation - for example scanning through a 80 GByte hard drive looking for specific files. If you would do this in the main thread, your GUI part would become unresponsive - in other words the user would click on something and nothing would happen for a long time. If you instead put the scanning of the hard drive into its own thread, your GUI would stay responsive for user input.

Another example would be if you use at least 2 CPU's. There is no *real* multithreading with one CPU since the CPU simply can only work in a sequential order. Of course...since it is working so fast, it *seems* that it is actually doing two things at the same time. However, having two CPU's you actually can really have two things being worked on at the exact same time. Nevertheless, getting the timing of such an application right is even harder. Many programmer's experienced that their multithreaded application works fine on a single CPU but doesn't on a dual CPU machine.

Getting things right and avoiding an overuse of multiple threads is a long learning process...and much experience... :cool:

[Sam Hobbs]

I think a thread should be used when there is both:

asynchronous events
a need for processing of the asynchronous events independent of other processing

In the case of worker threads, the asynchronous events might only occur in the main thread and the worker thread might be used only to allow the main thread to process asynchronous events (usually window messages).

A thread is often not needed when there is no processing required for an asynchronous event, right? Usually if there is no processing required for an asynchronous event, then it is possible to simply use synchronization functions such as WaitForSingleObject, right? A thread would also not be useful if there is nothing happening asynchronously, right?

[dimm_coder]

Like Andreas have already pointed out, threading is a complex question. For effective application of multithreading, someone should know some basics of OS theory.
Partly, threading helps to orginize logically a program design too.
For example, take a look on the next. Say, at some stage of algorithm it is necessary for us to execute N various independent one from other calculations (something like calculations under matrix elements). We cannot go on the next algorithm stage before comleting all these calculations and these calculations _have not to deal_ with some blocking operations (like operations with disk).
So the best approach for a single CPU machine is to perform calculations consistently.
But in common case, if U have M CPUs, U can have up to M threads for these calculations.
Of course, U can run N threads (one per calculation), but that will be shown in unnecessary contex-switching and flushing of CPU caches.
But another case, if these calculations _have to deal_ with disk and thus can be blocked for some time (waiting while read-write operation will be completed). In that case, we can run some threads in parallel (even for single CPU). While some thread is blocking, another one can use a CPU.
So, that's a complex complecated question and the right approach depend on various details.
...
The question is not - to use threading or not, but - to use correctly.

Here U can find some points of view on using threads for server applications.
http://pl.atyp.us/content/tech/servers.html

[Sam Hobbs]

In my opinion threads and multithreading is not especially complicated but that is my opinion; I can't prove that or argue that. However I will agree that answering the question is complicated and not easy. I don't have a good answer and I think the answer would require a lot of time to develop. However I think for most situations, it should be reasonably clear whether multithreading is useful if a person understands what multithreading is.

I think the question of whether multithreading is useful for a particular situation is relatively easy most of the time, but the question of how to use multiple threads can be quite complicated.

[KevinHall]

Perhaps an oversimplified rule of thumb should be:

Only multi-thread when a single thread can't do the job.

Now, there might be an app that is more difficult to maintain as a single threaded app than a multi-threaded app, but I think that would be pretty rare!

Just my 2 cents!

- Kevin

[Orf]

Thanks for your opinions.
I want to tell you something more speecific about what I'm doing.
I'm developing an MPEG2 multichannel player based on hardware decoders. The decoder's driver can send me events throug a callback function or through Windows messages. The player uses MIDI to accept interactions, and even with MIDI I can choose between callback or messages.
Some time ago (when I felt in love with multithreading :p ) I used two callbacks. Now I decided to use messages with both devices.
Obviously, I'm still dealing with threads - as I can see from my debug window - but the windows procedure handle everything for me.
I think in this situation this is the better choice, but I really care about other developers opinions and experiences.
Thanks and best regards.