CODEWITHSUNDEEP
multithreadingconcurrencyscalability
Sudhagar
Sudhagar

Reputation: 188

How exactly does multithreading work?

I would like to know how exactly multithreading solves the problem of scalability.My basic understanding is when a request comes in a new thread is alloted to serve the request.But what exactly happens behind the scenes.

I am currently starting a project where I have to build a Storage cloud to handle 1000s of GET,PUT,DELETE operations.Will multithreading address scalability or should I look into evented servers?

Upvotes: 4

Views: 18021

Answers (4)

Houcem Berrayana
Houcem Berrayana

Reputation: 3080

The multithreading can help because usually a normal HTTP execution contains many I/O. And as you know IO operations are heavy and take much time. So in practice when you have 1 request in which you need to fetch an instance of class A and an instance of class B if you create 2 threads one to access A instance and the other to access the instance of class B from database, you can load each instance on a separate thread, this way you will have more probability that thread A executes its code while thread B is blocked on the IO and inversely. So with multithreading you can win IO processing times.

This the first benefit. Another benefit that with multithreading that you don't have to reserve a hole thread for your incoming connection but use an asynchronous event processing model. There is a great implementation that uses this technique called netty that can handle 50 000 + requests per second.

Upvotes: 1

SARIKA
SARIKA

Reputation: 27

A thread is a smallest unit of task. When a task/thread is waiting for i/o or other things, it will be taken offline and other thread will start executing. This happens in fraction of micro seconds. Also if we have multiple processors we can have that many threads run simultaneously.

We need to be cautious on what we can make as thread. One thread should not depend on another threads output. In this case multi threading concept will give fast results. Some times we need to have the dependency on other threads. At that time we use synchronization.

If all your operations can take parallel path, multi threading improves the performance. If the operations are dependent on one another then you can look at evented servers.

Upvotes: 0

RalphChapin
RalphChapin

Reputation: 3158

Multithreading lets run more than one thread at once. On a multicore machine, this means two threads can really run in parallel, doing twice the work they'd do running one at a time. Ideally, on a 4 core machine, with 4 threads you'll get almost 4 times as much work done as with a single thread.

For this to work, you need a problem that can be solved with multiple threads running somewhat independently. You'll need to be fairly clever to figure out how to break the program into threads. And, most times, you'll need to be really clever to keep those threads from trashing each other's data (or, worse, subtly sabotaging it). Though it is sometimes possible to run the threads almost independently, like different sessions of the same program, which is nice when you can do it.

Multithreading scales in that you make all the cores work. On a 4 core machine, you get 4 times as much work done--hopefully. If you upgrade to a 16 core machine, you'll get another 4-fold increase--if you did some really clever programming. If you are boasting that you are 50% faster than your competitor, you'd better go with multithreading before your competitor does.

Otherwise, use a single threaded solution. It's a lot simpler. (Thousands does not sound like a lot of data to me. If it could go to millions, multithreading might be worth it.)

Upvotes: 6

kworr
kworr

Reputation: 3674

The only thing multithreading is better at is multicore calculations.

Generally event model is more lightweight as you can fully control code execution. For example if you are currently grabbing and processing HTTP headers and some other thread needs to wake up this means:

  • full processor state gets saved;
  • current cpu cache is patrly thrashed;
  • some code runs;
  • full processor state gets restored.

In event model you will have full right to end your whole cycle, save data and you will go for another event. Second event will wait until you finish your job. However time you would spew by hijacking working code is generally much bigger.

Memory management also takes count: in threading model you need locks to synchronize access to vital data, yet event model doesn't need locks nor extra memory per thread specific data.

That's also the point behind webservers: this way nginx can handle thousands connections without thrashing the machine.

Upvotes: 1

Related Questions