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

I have close to 3 years experience writing web applications in Java using MVC frameworks (like struts). I have never written multithreaded code till now though I have written code for major retail chains.

I get a few questions on multithreading during interviews and I answer them usually (mostly simple questions). This left me wondering how important is Multithreading in the current industry scenario ?

share|improve this question
You may not have done so explicitly but you have definitely taken advantage of it behind the scenes. – Loki Astari Sep 19 '11 at 17:45
I too rarely work with multi-threaded code for work, but I do try to read up on it / be able to discuss it during an interview. I would not want to work with coders who do not get threads, and I would not want to work with coders who do not care whether other coders get threads. – Job Sep 19 '11 at 17:47
I rarely use it in web development, but I think it's more common elsewhere. For instance, I was recently writing an Android app and realized you're required to use multithreading if you have any network activity. – jwegner Sep 19 '11 at 19:15
It's not multithreading that's important, it's parallel computing. If you think that everything single request that goes to your web app is on the thread... you must be smoking something. – user606723 Sep 19 '11 at 19:55
The ability to "Think outside the thread" is very nice even for single threaded programming. You take a lot less for granted, and your code is generally more robust and reusable. – corsiKa Sep 19 '11 at 21:10

14 Answers 14

up vote 80 down vote accepted

It is extremely important.

What is more important though is to understand that multithreading is just one way to solve the asynchrony problem. The technical environment in which many people are now writing software differs from the historical software development environment (of monolithic applications performing batch computations) in two key ways:

  • Many-core machines are now common. We can no longer expect clock speeds or transistor densities to increase by orders of magnitude. The price of computation will continue to fall, but it will fall because of lots of parallelism. We're going to have to find a way to take advantage of that power.

  • Computers are now heavily networked and modern applications rely upon being able to fetch rich information from a variety of sources.

From a computational standpoint, these two factors essentially boil down to the same core idea: information increasingly will be available in an asynchronous fashion. Whether the information you need is being computed on another chip in your machine or on a chip halfway around the world doesn't really matter. Either way, your processor is sitting there burning billions of cycles a second waiting for information when it could be doing useful work.

So what matters now, and what will matter even more in the future, is not multithreading per se, but rather, dealing with asynchrony. Multithreading is just one way to do that -- a complicated, error-prone way that is only going to get more complicated and more error-prone as weak-memory-model chips become more widely used.

The challenge for tools vendors is to come up with some way better than multithreading for our customers to deal with the asynchronous infrastructure they'll be using in the future.

share|improve this answer
+1 for an excellent answer, it deserves more credit than my own humble attempt. – Péter Török Sep 19 '11 at 20:22
Information increasingly will be available in an asynchronous fashion. If that ain't the truth. . . – surfasb Sep 19 '11 at 20:55
concurrency is more important than asynchronous behavior. You can have asyncronous without concurrency ( ie multiple threads on a single core CPU ) asynchronous is not a semantic substitute for concurrency. – Jarrod Roberson Sep 20 '11 at 17:18
@Jarrod: Taming asynchrony is more important than merely taming concurrency for precisely the reason you mention: concurrency is just a particularly difficult kind of asynchrony. The difficult part of concurrency is not the "things happening at the same time" aspect of it and indeed, concurrency is often only simulated concurrency, eg, non-cooperative multitasking via time slicing. The difficult part is in efficiently using resources without blocking, hanging, deadlocking, and without writing inside out programs that are hard to reason about locally. – Eric Lippert Sep 20 '11 at 18:27

It is getting ever more important as modern processors have more and more cores. A decade ago most of the existing computers had only a single processor, so multithreading was important only on higher-end server applications. Nowadays even basic laptops have multicore processors. In a few years even mobile devices... So more and more code is required to use the potential performance advantages of concurrency and to run correctly in a multithreaded environment.

share|improve this answer
+1: More important than ever. Remember too that in a system design, you can also get the benefits of multithreading just by partitioning the work so that more processes are doing it. – Scott Wilson Sep 19 '11 at 13:15
Quite a few mobile devices already have multi-core processors! – Che Jami Sep 19 '11 at 16:58
I'd argue that multi-threading has been important since the first time-sharing system was built. Having multiple processors/cores just adds a new dimension of efficiency to having multiple threads. – jwernerny Sep 19 '11 at 17:43
Maybe (especially on mobile devices) threads is a bad idea. The OS should probably handling optimizing the usage of the cores without having buggy user code attempting to do threading. There are very few applications a normal user has access to that need or would benefit for multitudes. The only exception are (high end graphics applications/developers tools/weather modelling/Web servers (and associated services)) all very high end specialized applications. – Loki Astari Sep 19 '11 at 17:49
@Tux-D, you may very well have a game on a mobile device which utilizes more than one core. It's not something exceptional. – whitequark Sep 19 '11 at 19:17

In general, multi-threading is already quite important, and is only going to get more important in the next few years (as Péter Török) pointed out - it is how processors will scale for the forseeable future (more cores instead of higher MHz).

In your case, however, you seem to be working mainly with web applications. Web applications, by their nature, are multi-threaded due to the way your web server processes requests for each user (i.e. in parallel). While it's probably important for you to understand concurrency and thread-safety (especially when dealing with caches and other shared data), I doubt you will run into too many cases where it's beneficial to multi-thread the web application code internally (i.e. multiple worker threads per request). In that sense, I think being an expert at multi-threading is not really necessary for a web developer. It's often asked in interviews, because it is quite a tricky subject, and also because many interviewers just google up a few questions 10 minutes before you get there.

share|improve this answer
+1 for the note that the poster is a web developer and most web server containers do a decent amount of multi-threading work for you. Not that it eliminates the need in some cases, but 99% of the time multi-threading controller code isn't the biggest performance improvement for an MVC call. – Mufasa Sep 23 '11 at 17:27

Multi-threading is a red herring. Multi-threading is a implementation detail to the real problem which is Concurrency. Not all threaded programs are concurrent because of locks and what not.

Threads are only one model and implementation pattern for implementing concurrent programs.

For instance you can write highly scalable and fault tolerant software without every doing any multi-threading in languages such as Erlang.

share|improve this answer
+1 although I still think Erlang is multi-threaded; the community just redefined the word "thread" to depend on mutable shared state, and thus distinguish themselves from it. – Dan Sep 20 '11 at 4:38
the Erlang VM usings 1 thread per CPU by default, but as an Erlang developer, you don't have access to the underlying OS threads only the light weight processes that the Erlang VM supplies. – Jarrod Roberson Sep 20 '11 at 17:16

I get a few questions on multithreading during interviews...

Well for passing the interviews, multithreading might be quite important. Quoting self, "when interviewing candidates for our team, I ask concurrency questions not because these skills are important in our project (these are not) but because these somehow make it easier for me to evaluate general knowledge of language we use..."

share|improve this answer
Having some idea about multithreading and concurrent programming also usually translates to a defensive approach, which can be a very good thing. If you have to take into account that something entirely unrelated within your process may or may not preempt a single logical statement and execute in the middle of everything else, then you have to plan for that possibility. Multithreaded implementations (as opposed to other forms of concurrency) simply means that you have the additional burden of that it may do something to any state that isn't thread-local. – Michael Kjörling Sep 20 '11 at 7:49

Understanding how to leverage threading to improve performance is a critical skill in today's software environment, for most industries and applications.

At a minimum, understanding the issues involved with concurrency should be a given.

The obvious note that not all applications or environments will be able to take advantage of it applies, for example in many embedded systems. However it seems as though the Atom processor (et al) seem to be working to change that (lightweight multicore starting to become more common).

share|improve this answer

Sounds like you're already writing multithreaded code.

Most Java web applications can handle multiple requests at the same time, and they do this by using multiple threads.

Therefore I'd say it's important to know the basics at least.

share|improve this answer
<nitpick>apparently (s)he isn't writing multithreaded code, only (single threaded) code which is run in a multithreaded environment.</nitpick> – Péter Török Sep 19 '11 at 12:59

It's still important in situations where you need it, but like a lot of things in development it's the right tool for the right job. I went for 3 years without touching threading, now practically everything I do has some grounds in it. With multi-core processors there's still a great need for threading, but all the traditional reasons are still valid, you still want responsive interfaces and you still want to be able to deal with sync and get on with other things at once.

share|improve this answer

Short answer: Very.

Longer answer: Electronic (transistor-based) computers are fast approaching the physical limits of the technology. It is becoming harder and harder to squeeze more clocks out of each core while managing heat generation and the quantum effects of microscopic circuits (circuit paths are already being placed so close together on modern chips that an effect called "quantum tunneling" can make an electron "jump the tracks" from one circuit to another, without needing the proper conditions for a traditional electrical arc); so, virtually all chip manufacturers are instead focusing on making each clock able to do more, by putting more "execution units" into each CPU. Then, instead of the computer doing just one thing per clock, it can do 2, or 4, or even 8. Intel has "HyperThreading", which basically splits one CPU core into two logical processors (with some limitations). Virtually all manufacturers are putting at least two separate CPU cores into one CPU chip, and the current gold standard for desktop CPUs is four cores per chip. Eight is possible when two CPU chips are used, there are server mainboards designed for "quad quad-core" processors (16 EUs plus optional HT), and the next generation of CPUs is likely to have six or eight per chip.

The upshot of all of this is that, to take full advantage of the way computers are gaining computing power, you must be able to allow the computer to "divide and conquer" your program. Managed languages have at least a GC thread which handles memory management separately from your program. Some also have "transition" threads which handle COM/OLE interop (as much for protecting the managed "sandbox" as for performance). Beyond that, though, you really have to start thinking about how your program can do multiple things simultaneously, and architect your program with features designed to allow pieces of the program to be handled asynchronously. Windows, and windows users, will practically expect your program to perform long, complicated tasks in background threads, which keep the UI of your program (which runs in the program's main thread) "responsive" to the Windows message loop. Obviously, problems that have parallelizable solutions (like sorting) are natural candidates, but there are a finite number of types of problems that benefit from parallelization.

share|improve this answer

Just a warning about multithreading: More threads don't mean better efficiency. If not managed properly, they may slow down the system. Scala's actor improve upon Java's threading and maximize system usage (mentioned it as you're a Java developer).

EDIT: Here's are some things to keep in mind about the downsides of multithreading:

  • interference of threads with each other when sharing hardware resources
  • Execution times of a single thread are not improved but can be degraded, even when only one thread is executing. This is due to slower frequencies and/or additional pipeline stages that are necessary to accommodate thread-switching hardware.
  • Hardware support for multithreading is more visible to software, thus requiring more changes to both application programs and operating systems than Multiprocessing.
  • Difficulty of managing concurrency.
  • Difficulty of testing.

Also, this link might be of some help about the same.

share|improve this answer
This doesn't seem to answer the OP's question :-/ – Péter Török Sep 19 '11 at 13:04
It gives a top(most) level view of threading, though. A thing to consider before delving into multi-threading. – c0da Sep 19 '11 at 13:08
@c0da Stack Exchange isn't a discussion board: answers should directly answer the question. Can you expand your answer to bring it back to what the asker is looking for? – user8 Sep 20 '11 at 0:32

My machine has 8 cores. In Task Manager, I have 60 processes running. Some, like VS, use up to 98 threads. Outlook uses 26. I expect most of my memory usage is the stacks allocated to each of those idle threads.

I'm personally waiting for the 300-core computer to come out so that I don't have to wait for Outlook to respond. Of course by then Outlook will use 301 threads.

Multi-threading only matters if you are building systems that will be the only important process on the computer at a particular time (e.g., calculation engines). Desktop apps would probably do the user a favour by not using up every available core. Web apps using the request/response model are inherently multi-threaded.

It matters to framework and language designers, and back-end systems programmers - not so much to application builders. Understanding some basic concepts such as locking and writing async code is probably worthwhile though.

share|improve this answer
I will often whack something on a background thread such as a long DB load, but its very rare I have to deal with race conditions or locks etc. (in fact probably never) – Aran Mulholland Sep 19 '11 at 23:00

Concurrent and parallel programming is what is becoming important. Threads are just one programming model of doing multiple things at the same time (and not in pseudo-parallel like it used to be before the rise of multi-core processors). Multi-threading is (IMHO fairly) criticized for being complex and dangerous since threads share many resources and the programmer is responsible for making them cooperate. Otherwise you end up with deadlocks which are hard to debug.

share|improve this answer

Since we may need to contact many external applications, there may be some background process should occur where the external system interaction takes more time and end user can't wait till the process is done. so Multithreading is important..

we are using in our app, we first try to contact external system if it is down then we save the request in Database and span a thread to finish the process in backgound. May required in Batch operations too.

share|improve this answer

Historically people had to struggle by doing multithreaded programming by hand. They had to work with all of the core components (threads, semaphores, mutexes, locks, etc.) directly.

All these efforts resulted in applications that were able to scale by adding additional cpus to a single system. This vertical scalability is limited by "whats the biggest server I can buy".

Nowadays I see a shift towards using more frameworks and different design models for software design. MapReduce is one such model which is focused towards batch processing.

The goal is scaling horizontally. Adding more standard servers instead of buying bigger servers.

That said the fact remains that really understanding multithreaded programming is very important. I've been in the situation where someone created a race condition and didn't even know what a race condition is until we noticed strange errors during testing.

share|improve this answer

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.