Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Concurrent programming is quite difficult to me: even looking at a basic slide seems challenging to me. It seems so abstract.

What are the benefits to knowing Concurrent programming concepts well? Will it help me in regular, sequential programming? I know there is a satisfaction to understanding how our programs work, but what else?

share|improve this question
I think it's kind of off topicky, but can get kind of on topicky if you edit out all the personal stuff (although concurrent programming is quite difficult to everyone) and ask for the concrete technical merits of the concepts. –  Yannis Rizos Oct 21 '11 at 2:47
The benefits should be quite obvious. You can write programs that can take advantage of all of the performance enhancements available through division of work that concurrent programming offers. It's not easy for anyone. It's a very challenging concept today. –  Rig Oct 21 '11 at 3:04
We can't help you get motivation to learn something, but the general question about why one ought to know about concurrency is on-topic enough. –  user8 Oct 21 '11 at 5:59
I know concurrent programming. I can tell that the slide you provide does not help to understand. Instead, go to a party with dining philosophers. –  mouviciel Oct 21 '11 at 7:37
Relax, even the greatest find it difficult: informit.com/articles/article.aspx?p=1193856 –  SK-logic Oct 21 '11 at 10:32
show 7 more comments

8 Answers

up vote 25 down vote accepted

Here's a quick and easy motivation: If you want to code for anything but the smallest, weakest systems, you will be writing concurrent code.

Want to write for the cloud? Compute instances in the cloud are small. You don't get big ones, you get lots of small ones. Suddenly your little web app is a concurrent app. If you designed it well, you can just toss in more servers as you gain customers. Else you have to learn how while your instance has its load average pegged.

OK, you want to write desktop apps? Everything has a dual-or-more-core-CPU. Except the least expensive machines. And people with the least expensive machines probably aren't going to fork over for your expensive software, are they?

Maybe you want to do mobile development? Hey, the iPhone 4S has a dual-core CPU. The rest won't be far behind.

Video games? Xbox 360 is a multi-CPU system, and Sony's PS3 is essentially a multi-core system.

You just can't get away from concurrent programming unless you are working on tiny, simple problems.

share|improve this answer
While I agree in principle, to say that Everything has a dual-or-more-core-CPU. Except the least expensive machines. seems a little preposterous. Lots of people have single-core machines, not because it was cheap, but because they are happy with what they have and see no need to upgrade. That said, thinking in terms of concurrency will help the scheduler on a single-core system as well, so it is not wasted effort anywhere you can assume preemptive multitasking, either (which is about every multitasking environment most developers will come in contact with, these days). –  Michael Kjörling Oct 21 '11 at 11:38
ok - that's a bit of an exaggeration, but new hardware tends overwhelmingly to be multi-core. I don't see that going away. So if you are a student today thinking about the work you will be doing professionally in the future it is safe to assume that you will be working on multicore systems. –  ObscureRobot Oct 21 '11 at 12:09
I wonder if i disagree with your answer as much as you would disagree with mine lol ;) –  acidzombie24 Oct 22 '11 at 1:26
The way I read it, there is a kernel of similarity to what we are both saying, @acidzombie24. I'm saying that a developer should know how to deal with concurrency because it will be everywhere. You are saying that you don't have to be good at concurrent programming as long as you ... avoid the pitfalls of concurrent systems :) –  ObscureRobot Oct 22 '11 at 2:10
I agree it's very useful to know about concurrency, but disagree you can only get away from it for "tiny, simple problems". You can get away from concurrency a great deal, even in non-trivial systems, for example if you rely on existing frameworks and application servers. Once the infrastructure is in place, I can be a junior developer writing new services for a web app and know almost NOTHING about concurrency or parallelism. –  Andres F. Nov 1 '13 at 16:39
show 11 more comments

From 1970 to about 2002 processors doubled in speed about every 18 months. So as a programmer all you had to do was wait and your program would go faster. The problem is that around 2002 the rules changed. Now they are not making bigger fast processors they are making smaller slower processors but putting them out in groups. The computer I am working on now has 4 cores, and Chips with up to 8 cores (and 4 threads per core) exist. Soon enough we will have chips with a lot more cores.

So if you write a program that is not at all concurrent you will find that you are using 1 core or thread, but the rest of the CPU is sitting there doing nothing. So if you have 16 cores 1 will be running your program and the other 15 are sitting there!

The problem with concurrency is that it is non deterministic. Which is to say that you don't know exactly what order different threads will do things in. Traditionally programmers have tried to solve this by using locks and the like. This has lead to a LOT of pain. Having some form of mutable state that more than one thread can access freely is often a formula for pain and heisnebugs!

Of late the trend has be to moving to functional languages which tightly control mutable state. There are two basic ways that functional languages handle concurrency. The first is by using message passing. This is best shown by Erlang. In Erlang there is in general no Shared state between processes. They communicate not by sharing memory but my passing messages. This should make sense to you as we are doing it right now. I am sending this information to you by sending you a message, not by you remembering it out of my brain! By switching to message passing most of the locking bugs simply go away. In addition messages can be passed over the network as well as within one node.

The other method is STM, which stands for Software Transcriptional Memory, This is present in clojure and Haskell (and others). In STM memory is shared but changes can only be made via a transaction. As the Database folks figured all this stuff out in the 1970's it is pretty easy to ensure that we get it right.

Actually I over simplified a bit, Clojure and Haskell can both do message passing, and Erlang can do STM.

Disclaimer I am the author of Programming Web Services with Erlang, which will be out in Early release in the next few weeks.

share|improve this answer
Excellent answer. Thank you. –  Adel Oct 21 '11 at 7:31
@Zachary K: are there approaches that blend functional languages with native languages so that computation-intensive parts are implemented in the native language but they provide interfaces that can be consumed by a server written in functional language? –  rwong Oct 21 '11 at 10:50
Not 100% sure, but both Clojure and Scala exist on the JVM, so that is where I would start. Maybe take a look at the Akka framework. I have not used it but did listen to a talk about Akka a while back and it seems like it might be pretty cool. For now I'm doing Erlang and Javascript which is taking up most of my time! –  Zachary K Oct 21 '11 at 11:16
@rwong: .NET lets programmers use C# or other non-functional languages for some parts of their apps and F#, a functional language, for others. –  Kevin Nov 2 '13 at 0:34
add comment

Because concurrency can blow in your face when less expected...

share|improve this answer
+10000000000000000000000000000000000000000 –  acidzombie24 Oct 21 '11 at 8:56
Concurrency is the new Spanish Inquisition [/python] [as in: no one expects...] –  ObscureRobot Oct 21 '11 at 12:12
@ObscureRobot twice as funny! (the explanation wasn't needed :-p) –  fortran Oct 21 '11 at 12:17
add comment

The first rule of concurrent programming is "It's difficult". The second rule of concurrent programming is "It. Is. Difficult"..!!

Seriously though, there are two common approaches to concurrent programming, multi-threading and multi-processing. Multi-processing is the easiest to comprehend since it just means having multiple instances of a process running to accomplish a task. The is pretty easy to do on Unix based systems via calls to fork/join, but not so easy on Windows systems.

Multi-threading is probably the approach most people think of when talking about concurrency. It's not difficult to start multiple threads within an application, but the devil is in the details. You need to co-ordinate data sharing between thread (usually using locks) which can lead to deadlock or data in an invalid state. You also need to understand how to communicate between thread using concepts like semaphores, conditional variables etc etc.

The advantage to all this is that once you understand it you're able to more effectively utilize the underlying hardware. These days it's pretty much the norm for a processor to have multiple cores. By utilizing concurrent programming you can make these cores work for you, and your application will get a speed improvement.

The disadvantage is that you have to start thinking about how you'll split your application up into small parts that can be run on different threads. This is a lot harder than it sounds. Also, highly concurrent solutions can be awkward to unit test as the order of execution is less deterministic.

These days most languages ship with an abstraction over most concurrent primitives to make life a bit easier. For example, .NET 4 ships with the Task Parallel Library which make life a bit easier. In Java land they've got the Concurrency package.

share|improve this answer
It gets orders of magnitude if you run away from locks as fast as possible. Use STM or actors and all of what you said goes away. Of course that means moving away from Java to languages like Scala, Erlang or Clojure. (though I would argue that this is also a good thing) –  Zachary K Oct 21 '11 at 11:53
@Zachary: It may be a good thing, but if you working in a .NET shop, for example, it's not practical. STM may be an option in the future, but right now it's not an option in mainstream languages. –  Sean Oct 21 '11 at 11:57
Clojure runs on .net, and there is F#. I would bet that there are also STM implementations for C#. –  Zachary K Oct 21 '11 at 11:59
add comment

I recently had a very interesting task to do in which multiprocessing saved me. I basically had to do a lot of requests to a few separate servers, dealing with very small amounts of data, but many requests.

Working with PHP, I did things the old fashioned way, and the best time I obtained after a few hours of work resulted in ~120 seconds to run a certain test (many requests + network delay + no async)

But that wasn't nearly enough compared to what I needed, and after failing miserably with PHPs multiprocessing, I switched to Python.

After a few hours, I had a running Python multiprocessing script that ran in 20 seconds, and after a bit of fiddling with the timeouts and no. of threads to be used, I got it down to ~10 seconds.

This was for a website written 100% in PHP, except a single, 100 line Python script. And the whole thing is working perfect.

My conclusion would be that even if it won't help you on a day to day basis, you may encounter situations where knowing at least the basics of concurrent programming will help you greatly.

Good luck, and happy coding!

PS: I'm not trying to bash PHP, but PHP simply wasn't the right tool for the job at hand.

PS2: Knowing a new technology, or a new way of doing things can open the door to a whole new world of possibilities.

share|improve this answer
add comment

If you do any sort of web development, concurrency comes into play, at least with most languages. For example, I use spring for web development and each new request comes in as its own thread. Therefore, if any request ends up accessing a shared object, where the state can be changed of a variable, concurrency is very much a factor and has to be taken into consideration. If its not, then the data can be edited in unpredictable ways and data corruption can result. Its not critical to know every last detail about concurrency but learning pieces at a time is important to better understand web app programming, if you are working on desktop apps, maybe its not so important unless you need to run multiple threads

share|improve this answer
add comment

You shouldnt. Maybe if you do performance programming then you'll need to consider it but AFAIK no one does it for client software as it doesn't need much CPU time and threads are used for the users other software

-edit- All the concurrency code should be handled in frameworks or libraries. (for an example websites will have pages being handled simultaneously for you). You may have to learn how to write DB queries that relys on order (for example calling get_last_rowid() as its own query even within a transaction is a bad idea). You'll need to learn some restrictions in some concurrent work but really most libraries let you handle it and as long as you dont use shared variables then your fine. I am saying you definitely shouldn't be writing the code that takes care of threads and such.

share|improve this answer
Good insight. Thanks –  Adel Oct 21 '11 at 7:31
@Adel haha thanks. I known about concurrent programming and of the dozens of software (many are utils or scripts for backups, renaming torrent files to match a db, hex editor, etc) and websites i made over the years i STILL haven't found a place where i should use it. The most CPU i used was by launching ffmpeg or imagemagik to do some processing. –  acidzombie24 Oct 21 '11 at 7:36
short sighted! The world is concurrent, so is your domain model in many cases. Even in the case were you may not be thinking about it. Ever have more than one user on a web site? –  Zachary K Oct 21 '11 at 8:52
And, by the way, if you're coding in PHP (I suppose that you're using it for web apps), you're already doing a lot of concurrent programming. Guess why? Communication between a browser and a web server is asynchronous. If you're playing the RESTful game - you're already versed in the message passing-based concurrency. –  SK-logic Oct 21 '11 at 10:41
The dangerous thing about @acidzombie24's answer is that acid clearly knows enough about concurrency to avoid the common pitfalls, but is suggesting that it isn't necessary to know about concurrent programming. Everyone should know the basics, it is your own loss if you don't want to learn how to use concurrency to your advantage :) –  ObscureRobot Oct 23 '11 at 0:13
show 20 more comments

Learn the insight of operating systems. Reading the source code of schedulers and device drivers will help; they are definitely concurrent.

share|improve this answer
Concurrency for programmers usually go for your own programs running in multiple instances. –  user1249 Oct 21 '11 at 7:54
I tried to emphasize you can't write your own concurrent program anyway without knowing the details of the scheduling algorithm of the OS kernel. –  jj1bdx Nov 3 '11 at 11:20
Why not? If you use the locking mechanisms correctly the OS scheduling algorithm is unimportant. –  user1249 Nov 3 '11 at 11:39
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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