How important is multithreading in the current software industry?

Question

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 ?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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..."

Answer 6

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).

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.