Is this push towards parallelism really that good?

[abcdefgqwerty]

multithreading problems have been around for 20 years numerous research papers. No one ive ever seen has completely even solved some of these problems. I mean more threads means a much much more complex program to start and more threads waiting around to access a resource thats just locked anways so some threads arent even being used. Multithreading just seems like more work being pushed onto programmers when researchers havent even figured out multithreading problems yet. I mean who can write a program with 8 threads being used concurrrently at all times with no chance at a deadlock anywhere? im not even sure its possible unless you try to move inactive threads around to different spots to keep them busy but that just increases chance of deadlocks or race conditions.
Your thoughts on future of multithreading? good or bad?

[MrViggy]

One great example of multithreading (and one reason why we can't live without it) is Windows itself. You have an application that does a lot of processing, but you want your GUI to remain active. IMHO, the only good way to implement this is to do the work in a separate thread from the GUI thread.

Viggy

[Arjay]

[this response is from a Windows-centric view)

Multithreading has been around for quite some time on Windows since NT's first inception.

When I first started in this business, one of the first books I read was 'Advanced Windows' by Jeffrey Richter. For Windows multithreading, it's a must have IMO.

Anyway the point is that multithreading has been available for 14 or 15 years and the concepts of protecting shared data have been around for at least that long.

What seems to be new is the notoriety surrounding 'parallel' programming with the advent of dual core machines, but in reality is this any different than programming multi-threads on a multi-processor machine?

Obviously the answer is no, because it doesn't really matter if the threads modifying shared data execute on a single proc machine, a dual core machine or a multi-proc machine, the shared data still needs to be protected.

Multi-threading may be more work, but it doesn't have to be very much additional work if it's approached propertly.

As far as the 8 threads problem. Using exception handling and taking a RAII approach to synchronization will go along way toward ensuring there are no concurrency or deadlock issues. Plus the RAII approach makes for much easier debugging.

I don't see the need to 'move threads around'. If the thread needs to wait for a resource, well, then it needs to be sleeping. Choosing the correct architecture, a reasonable number of threads and appropriate synch objects will minimize thread wait times. But allow the OS to schedule the threads; don't second guess the OS thread scheduler 'moving threads around.'

By appropriate sync objects, I mean use a cs, event or mutex as appropriate. If you have a high read, low write need with multiple read threads, then consider a MultipleRead/SingleWriter type lock object (in C++, you'll have to write your own; in C# you can use the ReaderWriterLock).

There are other strategies as well to minimize thread contention. Queuing, using copies of data, etc. A big one is using thread pools and/or minimizing the number threads used.

In terms of good or bad, as mentioned multithreading hasn't really changed. It's definitely good, when following a few simple rules.

That said, I'll leave you with a twist on the phrase "Drink Responsibly."

"Thread responsibly - don't use more threads than necessary."

[wildfrog]

My thoughts are that threads are here to stay (until they're replaced by something better). There are ways to avoid deadlocks and race conditions, but like almost every other type of bug, they're 'always' introduced by sloppy coding.

In many situations you can benefit from 8 threads without having the 8 threads interact with each other, and you can come a long way without trying to solve the dining philosophers problem.

And even if more threads will introduce more complexity, you can often isolate/encapsulate parts of you code in such a way that the extra complexity is kept at a minimum.

In these days with multiple processors and cores etc., more and more people 'see' the benefit of multiple threads, but often without knowing how to avoid typical pitfalls. My prediction (or hopes) of the future is that compilers/cpu (or whatever) becomes smarter and that parallelism is automagically added to your application, wherever suitable.

- petter

[JVene]

This thread touches on a few different target concepts for threading.

GUI threading, where the primary goal is to keep the GUI responsive, passing any task longer than a millisecond off to a thread.

I'm not sure that qualifies as parallel processing, per se - I'm not sure the definitions are hard and clean.

A fair example of parallel processing is in video/image processing. Depending on what is happening, the task can naturally break down into smaller portions, without any alteration of the result. Similarly, 3D rendering can be broken into 'buckets'. In many cases scaling is nearly as good as the number of processors (4x speed with 4 cores, 8x speed with 8 cores). In other cases, the results aren't so stellar - especially if the task is RAM bound, not processing duty bound.

In many parallel processing tasks, the division of the work is such that synchronization is trivial. One need merely observe when the last of the threads have finished in order to signal 'task completed'.

There are lock-free approaches, too.

Consider the reverse question, too. Why NOT utilize multiple cores to perform tasks which can be easily broken into parallel processes, as opposed to attempting to ramp up the speeds of processing compared to a single core?

And, why not toss off tasks behind the GUI, to keep it responsive?

In particular, a range of objects devoted to threads and synchronization, including smart pointers, make such threading almost trivial once you're practiced at it.

Even the dreaded deadlocks and race conditions are reduced to rare occurrences, because a good class library is based on known design patterns that usually yield excellent results.

[TheCPUWizard]

I have been developing multi-threaded applications for nearly 25 years. There are many situations that are basicly near impossible to implement (in a reliable and robust manner) without them.

Look at Intels latst processor. 80 (not a typo) cores. This means that the processor only starts to achieve full potential with at least 80 threads going. If the threads are blocked waiting on some external or internal event (and most non-computational bound threads spend 75%+ of their life in this state) then you need a minimum of 320 threads.

The real issue is creating proper code. Intel makes a complete language/library that handles parallism great. Consider finding the determinate of and NxN matrix. There are N parrallel operations that each can spawn N-1 operations, which can each spawn N-2 operations all the way down till N=2. Performing these calculations sequentially would take significantly longer. [In 1975 i had to program the computation of a 128x128 matrix. Granted computers were much slower then, but a single threaded operation on a DEC PDP-8 took 11 weeks!