Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In grad school I took a class in multiprocessor and distributed operating systems. I think multiprocessor software development will become increasingly important and will be driven by the need to maintain the gains we are accustomed to having from Moore's law as described in an article from Herb Sutter.

The Free Lunch Is Over : A Fundamental Turn Toward Concurrency in Software

From the class we learned a little about threads, processes, mutual exclusions, spin locks, p-threads, semaphores, UMA and CCNUMA architectures, and OpenMP. But I think this is just a start.

  • What should I learn to better prepare for this kind of work?
  • Who is doing projects in this area?
  • Is this going to a a common skill soon, and if so, how can I best leverage what I know today?
share|improve this question

closed as too broad by gnat, Dan Pichelman, ozz, Michael Kohne, Bart van Ingen Schenau Oct 1 '13 at 13:08

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

is this a c++11 only Question, or are other language specific answers welcomed ? – NWS Aug 14 '12 at 10:48
Sorry for the delayed response. I guess I did tag for C++11, but I am interested a little more broadly, so bring on your suggestions. – DeveloperDon Aug 21 '12 at 7:48
In Java, you can use CoralThreads to set thread affinity without needing any JNI/Native code. – rdalmeida May 2 '15 at 16:25

In the first place, multithreaded code is difficult to write and to debug. Most programmers can't do either, and the ones that can are hard to find and spend a lot of time to write a small amount of code. The result is that there's not a lot of enthusiasm for this.

The flip side is that the cores are becoming more numerous, not faster, so if people want to improve performce, they've got to dive in.

For the most part, the idea seems to be to push the multithreading onto someone else's software. Web servers try to be "stateless". That is, they save no data. Each call to the servers functions (methods) is handled on its own. Actual information is handled by databases and system classes with proven track records. In this way programmers that no one would trust near a volatile field can work hard on applications that, in fact, keep all the cores on a big machine going full tilt.

The other trick is to use parallel programming. Threads that don't share data can safely run at the same time, and most systems provide safe ways to run them without the programmer having to deal directly with locks, semaphores, etc.

On the other hand, it's easy to end up multithreading without intending to or without knowing what multithreading is. (People who do know what it is know to avoid it.) I have the uncomfortable feeling a lot of software is going to start to get a bit quirky--it works right most of the time, but every now and then it does something odd, and no one can reproduce it or track down the cause.

To attempt to answer your questions explicitly:

Tools? I've had good luck with Java, and C# ought to be as good. I don't know know about anything else. I expect the situation to improve a lot. My Netbeans (don't know about Eclipse) IDE generally tells me a lot more than I want to know about my code these days, but it won't--yet--tell me I've got a non-final non-volatile field used outside a synch block.

Who's doing projects in this area? Database developers. OS developers. Other people building tools for the rest of us. I'd expect game developers to be big on this, but they don't seem to be.

What should you learn to better prepare? I'd try writing a program with lots of threads that talk to each other a lot. Theory's important, but you need to do it as well. Also, while the theory (which I didn't get until after I tried to use it and made a big mess) helps a lot with avoiding bugs, it takes pure smarts to figure out how to keep your code from all hanging up waiting for a lock. Coding like this will give you a useful feel for multithreading, even if you never code--or want to code--like this again. Even if you stick with parallel programming and "stateless" code forever more. At least you'll know a MT bug when you see it.

Is this going to be common? Not until there's been a big improvement in languages and compilers. People writing core tools for other programmers (like databases) will do more and more. Multithreading's going to infiltrate a lot of code when no one's looking, and figuring out that this has happened and fixing the code is going to be a big business for anyone who can do it--and wants to. (This actually might become common.)

To be honest I don't know what's going to happen. Multithreaded programming has to take over, and soon. Who want's to sit around while their game/spread sheet/IDE/search engine takes forever to do a job while using 6.75% of the CPU? But how many people would you trust to produce a reliable multithreaded program? I suspect we'll have a handleful of MT programmers doing the MT work and everyone else staying reasonably singlethreaded.

share|improve this answer
Thanks for the helpful, if at times gloomy assessment of multithreading. I think it is more complicated, but offers potential if not misused or overused. I was on a project where the lead said no multithreading because we had a system that had trouble with threads. We ended up with several threads, and I think they helped. The follow on project started with a grand thread based design, but backed off to reuse code from the first system. On a desktop, there are always a lot of threads to run. – DeveloperDon Aug 21 '12 at 7:46
@DeveloperDon: I prefer "realistic" to "gloomy". You want to be aware of why people are afraid. You also want to be aware of all the people who are not afraid and should be. Sounds like you've seen enough to know. But CPU speed is stuck at 3-4 Ghz, and I don't think core count is stuck at all. The pressure to multithread will be irresistable. Even the people that don't need it are going to get dragged along. Should be fun. (Personally, I love it.) – RalphChapin Aug 21 '12 at 20:26

I think this is why the popularity of functional programming is on the rise; when state is immutable, locking/synchronizing isn't needed. Languages like Clojure are making multi-threaded programming much easier for programmers, and more reliable.

share|improve this answer
Do you have a good reference for Clojure threading, or an example that shows its advantage? – DeveloperDon Aug 21 '12 at 7:02 is a good place to start. – erturne Aug 21 '12 at 11:33

Ada has had multithreaded (multiprocessor) support since 1983. There is an informative wikibook, with plenty of links, including a good section on tasking, which is OS independent (Will work equally well on Windows as linux).

As this is also a 'career' type question, you will probably only use it if you are in a niche market where is is well suited to its design aims (realtime, mission critical, embedded).

Also beware people like dumping on Ada, usually because its not <insert favourite language here>, rather than any technical reason.

share|improve this answer
I am not inclined to dump on Ada. I have heard that it was object based, and a few years later object oriented languages started to arrive and stole some of its thunder. I remember hearing good things about rendezvous and it looks like they took care to encapsulate and make safe as many aspect of task driven concurrency as they could. Thanks for the links. – DeveloperDon Aug 21 '12 at 7:20
@DeveloperDon The other reason it got dumped on was that it was mandated by the US DoD. Perople pushed back agains this for non-engineering reasons. This was mainly in the 80s - early 90s. – NWS Aug 21 '12 at 7:36

IMHO there are two separate challenges when trying to do concurrent programming:

  1. how to use multiple threads in my application
  2. how to design a parallel algorithm for my problem

Adding thread based processing to an application is not for beginners and requires careful design and implementation. However concurrent programming is nothing new. Server environments have been doing it for decades and the tools and techniques you mentioned (threads/semaphores etc) are there. Done correctly you can use all the cores in the computer and speed up the startup time, UI reaction, processing, etc

Parallel algorithms have been developed over the years but there is still more potential and more solutions yet to be discovered. If you want to learn more try reading up on SIMD logarithms and heartbeat/systolic algorithms. Many years ago I was involved with a MASPAR (massively parallel) system with a processor containing 4096 (IIRC) very simple CPUs in a grid that could crunch data. There is still huge potential in data crunching, data mining or other problems that used to be only for supercomputers.

I don't think these are common skills but they are an in-demand skills.

share|improve this answer
Thanks, you make several great points. I wonder where we are on adoption and cost reductions for MASPAR and IIRC vs. something like CUDA which targets GPUs with lots of smallish processors. Every teenager in America seems to have a tricked out PC with an NVidea card, and many have dual/quad/or quad core hyperthreads, so it is a lot of places. In the developing world, the first computer may be a multicore ARM with a multicore GPU in a cell phone. – DeveloperDon Aug 21 '12 at 7:30
up vote 0 down vote accepted

Some traditional tools permit SMP, symmetric multiprocessing in which multiple processors, and more recently, multiple cores share a bus to a common memory, sometimes described as UMA for uniform memory addressing. This support can benefit from very early features including process based fork() and join() that have been around forever and utilize features of the virtual memory system to share page tables, particularly for code, and to be efficient by following a copy-on-write optimization where data pages are shared until one of the processes writes to it.

Other traditional approaches include the IPC (Inter-process communication) library which permits creation of blocks of shared memory, semaphores, and messages that can be exchanged between processes. I have heard of a library related to light-weight threads. pthreads (for POSIX threads) also can create and manage concurrency in terms of thread creation and has mutexes, conditional variables (their version of semaphores?), and synchronization.

As I understand Java threading, their are critical regions defined at method scope with the synchronized keyword, and methods wait(), notify(), notifyAll(). Variables can be defined volatile that puts a critical region around their access, but not necessarily enough for a read-update-write

One popular tool set for multiprocessor / multithread programming is OpenMP. Another is OpenCL. Some of these environments introduce new keywords into the programming languages. For example, the GCC compiler has directives and #pragmas with names like:

  • parallel
  • section
  • shared / private to designate how threads will access variables in memory
  • critical
  • atomic
  • barrier
  • set_num_threads (probably from some criteria like physical cores, amount of memory).

I think some of the necessary concepts will include:

  • spin locks
  • critical regions
  • mutex
  • semaphores
  • thread creation / termination
  • barrier synchronization
  • scheduling of tasks across cores/processors
  • task and data parallelism
  • reduction (i.e. results from a big computation can be joined together).

In a small amount of looking at OpenMP, it seems their programming model does not use semaphores, but perhaps semaphores belong to coarse grained-parallelism and OpenMP is going mainly for fine-grained, and allowing threads to block, then placing them in queues is wasteful or maybe it is handled by the compiler. It is very easy to mismatch P() and V() calls on semaphores, so perhaps the structure of OpenMP syntax eliminated the problem.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.