Multi-threaded

[Sionofdarkness]

I read somewhere that Java is "multi-threaded". What does it mean for a language to be multi-threaded? The thing that comes to mind is multiple uses, but basically all languages have multiple uses, so it can't mean that...

[WingedPanther]

A multi-threaded program is a program that allows different pieces of code to run at the same time. The advantage is that you can have a single program working on several things at once. The disadvantage is that you can actually have it run SLOWER than a regular program. You also introduce more potential for bugs, and it is generally harder to debug.

Right now, you should probably worry about getting comfortable with the other features of Java.

[Sionofdarkness]

So like any feature, it has it's advantages and disadvantages. It definately sounds very useful, as long as all the bugs could be worked out. Can all programs act as multi-threaded programs?

[WingedPanther]

They can, but many programs will get no benefit from being multi-threaded. One example that comes to mind is StarCraft. You could have each unit running on its own thread, but it is easier to store the units in a list and iterate down the list, updating each unit on each pass. It makes more sense to store the units in a list and just go down the list, because it's simpler to program and probably MORE efficient.

[Sionofdarkness]

Nice comparison, it seems the second time you explain things they always make more sense.

[WingedPanther]

Every concept you have asked about has a purpose in programming. The key is understanding what the purpose is and when to use it. Since some concepts are more complicated, they can take longer. And like most things, explanations often raise additional questions.

[brackett]

While I agree that, in a lot of cases, there's little benefit in multithreading *now* - the dual+ core revolution will soon turn that idea on it's head. The main reason multithreading doesn't benefit a lot of programs is that you're still only able to execute a single thread at once. Dual (and the coming 4 and 8 way CPUs) change that, and multithreading will become the main way to speed up an app.
Hopefully, compilers will catch up and start to multithread optimize on their own. Until that happens though, I'd suggest getting pretty comfortable with threads.

[amac]

Originally Posted by brackett

While I agree that, in a lot of cases, there's little benefit in multithreading *now* - the dual+ core revolution will soon turn that idea on it's head. The main reason multithreading doesn't benefit a lot of programs is that you're still only able to execute a single thread at once. Dual (and the coming 4 and 8 way CPUs) change that, and multithreading will become the main way to speed up an app.
Hopefully, compilers will catch up and start to multithread optimize on their own. Until that happens though, I'd suggest getting pretty comfortable with threads.

You're confusing the issue here. Multi-threading at OS level is a seperate issue from multi-threading at process level.

At the process level its often necessary to have a program with multiple threads, even if they don't actually execute concurrently. For example, you might want to listen to console input while also performing some other computation in the background. And that is important here and *now*.

[brackett]

Originally Posted by amac

You're confusing the issue here. Multi-threading at OS level is a seperate issue from multi-threading at process level.

At the process level its often necessary to have a program with multiple threads, even if they don't actually execute concurrently. For example, you might want to listen to console input while also performing some other computation in the background. And that is important here and *now*.

I'm not sure what you mean by confusing multi-threading at OS vs process level. Threads are always a part of a process, and whether that process is owned by your application or the OS is immaterial to the discussion, I think.

Due to context switches and locking on shared data, multithreading your example will likely end up running slower on a single core machine. Does that mean you shouldn't multithread? Not necessarily...performance is rarely a consideration of mine anymore. But, a lot of programmers (unfortunately) have issues designing, debugging, and maintaining multithreaded code. In the best case, you still have a whole class of new and exciting bugs and scenarios to worry about.

Now, you should spin off new threads from the UI thread for long running tasks - but that's somewhat of a special case, where blocking the UI thread has the unfortunate characteristic of blocking window updates and making your app appear hung. But, gratuitously multithreading doesn't make your code faster, doesn't make it any more maintainable, and doesn't lead to more reliable code...why do it, then?

In your example, you have a need to have a long running process that the user can cancel. You have 2 choices; break the long running process in manageable chunks and poll the input in between chunks, or set up a processing thread and an input thread that communicate with a shared data structure. The processing thread will still need to check the shared data structure to catch an abort request (or you could just kill the thread...but that's a bit extreme) and you'll need to add locking semantics to support simultaneous read/writes.

On a single core machine, I'd vote for the single thread solution. It'll likely be faster, and almost definitely be more maintainable. But, on a dual core machine, the 2 threads can be run on independent CPUs - so the multi threaded solution will be faster because the processing thread can take advantage of a dedicated cache with no context switch penalty.

[brackett]

Originally Posted by amac

You're confusing the issue here. Multi-threading at OS level is a seperate issue from multi-threading at process level.

At the process level its often necessary to have a program with multiple threads, even if they don't actually execute concurrently. For example, you might want to listen to console input while also performing some other computation in the background. And that is important here and *now*.

I'm not sure what you mean by confusing multi-threading at OS vs process level. Threads are always a part of a process, and whether that process is owned by your application or the OS is immaterial to the discussion, I think.

Due to context switches and locking on shared data, multithreading your example will likely end up running slower on a single core machine. Does that mean you shouldn't multithread? Not necessarily...performance is rarely a consideration of mine anymore. But, a lot of programmers (unfortunately) have issues designing, debugging, and maintaining multithreaded code. In the best case, you still have a whole class of new and exciting bugs and scenarios to worry about.

Now, you should spin off new threads from the UI thread for long running tasks - but that's somewhat of a special case, where blocking the UI thread has the unfortunate characteristic of blocking window updates and making your app appear hung. But, gratuitously multithreading doesn't make your code faster, doesn't make it any more maintainable, and doesn't lead to more reliable code...why do it, then?

In your example, you have a need to have a long running process that the user can cancel. You have 2 choices; break the long running process in manageable chunks and poll the input in between chunks, or set up a processing thread and an input thread that communicate with a shared data structure. The processing thread will still need to check the shared data structure to catch an abort request (or you could just kill the thread...but that's a bit extreme) and you'll need to add locking semantics to support simultaneous read/writes.

On a single core machine, I'd vote for the single thread solution. It'll likely be faster, and almost definitely be more maintainable. But, on a dual core machine, the 2 threads can be run on independent CPUs - so the multi threaded solution will be faster because the processing thread can take advantage of a dedicated cache with no context switch penalty.