I would only consider threads for allowing a message pump to continue while you work on a reasonably large task and preserve "user experience" (god, what a wank word).

I would try to cut it up into processes instead of threads. The tradeoffs are that you will not be using the same stack (cannot share memory as easily) but that also means you will have your own stack that doesn't need to wait on other threads to stop poking into your memory.

If you want to start threads quickly and end them quickly, threads do that with less overhead. However, it sounds that your processes will all be continuously running.

Edit: some of the above is incorrect and discussed below. It is kept here to maintain continuity for readers. This note is here to prevent multiple "omg you are wrong!" posts.

[Edited by - flangazor on November 25, 2004 7:37:22 PM]

Here you go. They maintain their own stack. Sorry.

On the positive side, that site explains everything I tried to, but correctly and in more depth.

Cheers, Extrarius!

Quote:Original post by flangazor
I would try to cut it up into processes instead of threads.

In general, this is very bad advice. Under windows, Processes cost a heck of a lot more than threads.

A process is a container for a thread. A process can not execute any code, thats what the threads do.

One plus is each process has a seperate address space, which can be very desirable if you are hitting the ~2gb-3gb virtual memory limit. Under WinXP 64, you can get 4gb of virtual address space for free when running 32bit apps(when indicating you are large address space aware), as the kernel is above the 4gb line.

Your processor has multiple units for doing calculations, some working with integer data of general purpose registers, others working with floating point data of SSE registers and so on.
Because there are more of such units than a single thread could fill in most cases, even when the processor does optimizations like out-of-order execution, a second thread working in parallel can utilize them in parallel. (Probably that's what 'igni ferroque' meant by 'to fill holes left by unoptimized code').
HT does only work on task that are cpu-bound. A second thread that is responsible for networking sleeps most of the time, and you won't benefit from HT there.

Quote:Original post by Anonymous Poster

Quote:Original post by flangazor
I would try to cut it up into processes instead of threads.

In general, this is very bad advice. Under windows, Processes cost a heck of a lot more than threads.

They cost more in the sense that they take more time to start and more memory for overhead and context switching is more of a bother. However, if you are writing a distributed application, then processes are they way to go. You can't have separate threads of the same process running on different machines. It isn't scalable.

Also, in real time systems (a lot of consumer products), separate processors being delegated to perform specific tasks are how things are done. You don't have a main program that spawns threads for your anti-locking breaks and the air conditioner.

Maybe I misread the OP's intention. They were thinking of the computer on their desk and I was thinking of the computers that serve the OP's webpages, rendered the special effects in their favourite movies (or even the whole movie if it's Pixar), calculated the weather patterns to tell them where hurricanes are going, perform telephone exchange switching, or even the several processors in their car handling the anti-locking brakes and shifting gears for them. Those are all pretty important to consumers.

Quote:Hmm... most people need a GPU, don't they? DSP chip for sound? What about the Playstation 3 which will be massively parallel? Or the Xbox 2?

No. Most people do not need a GPU. Most computers are for business and government work. For example, the US government is the biggest customer of Microsoft products (who therefore gave them much of their monopoly). Computers for most businesses do not need stencil buffers and they don't need DSPs for audio.

Even if you were right, and most computers needed GPUs and DSPs since all computers are home computers for gaming, this only supports what I'm on about. There is going to be little speedup from threads because everything that is an obvious task for a thread has been removed from software and many successful companies make hardware to perform that task (you only have one frame buffer (generally) and one audio being output at once and one ethernet connection at once). Bringing us back to general purpose processors giving limited returns on home computers.

(FWIW, I consider embedded sysems to be part of the computer industry and by extension, computers. Our potential disagreement may begin here.)

[Edited by - flangazor on November 25, 2004 7:19:52 PM]