• Post Reply Bookmark Topic Watch Topic
  • New Topic

How multithreading really helps?  RSS feed

 
manish ghildiyal
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am currently trying to understand concept of multi-threading in java, but finding it quite difficult to grasp.
My first issue is very basic, as follows:

Java multi threading API provides various means for inter-thread communication like wait(),notify() etc. Then we also have
concept of synchronization which enables us to prevent dangerous scenarios like race conditions etc. by allowing only one thread
to execute a given piece of code at a time.
But all this can easily make one think that by using all these facilities what we are basically achieving is that only one thread(of all the thread candidates) is executed
at any given point of time, JVM scheduler switching between them alternately.
If this is really the case then how does multi-threading really helps in improving performance of our program.Isn't multi-threading supposed
to enhance time based performance of a program by enabling multiple threads to execute at same time, while it seems that we are in-fact striving
to get only one thread getting executed at a given time by making use of facilities provided by java like wait, notify or synchronization.

And, are there any good resources like books etc which can explain multi-threading threadbare to starters like me.

Manish

 
Tony Docherty
Bartender
Posts: 3271
82
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A number of years ago when most PC's only had a single core processor most multi-threaded applications only ever had one thread executing at any one time, these days it's a little different as multiple cores and multiple processor systems allow some simultaneous execution of threads.

So why use multi-threading if you only have a single core processor? Well it's certainly not for raw throughput reasons because each switch to the next thread takes time and so you get less throughput than you would get from a single threaded application. But think about the situation where you press a button on screen and it the operation takes a few seconds to complete. In a single threaded application the GUI would freeze until the operation has completed and the single thread could return to service the GUI, whereas in a multi-threaded application you could perform the time consuming operation in the background on another thread and keep the GUI alive so you could carry on working.

In multi core/processor systems multi-threading can also improve raw throughput by executing tasks simultaneously.
 
Chan Ag
Rancher
Posts: 1090
14
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also to add to what Tony said -

Multithreading isn't always( though it mostly is ) about having threads that are synchronizing access to shared data. You could have simplest of threads that do not have any shared data. So if your application has say five such threads and some threads are involved in time consuming operations, the CPU can switch amongst the threads within one application and that increases the system throughput as well as decreases the elapsed time taken to execute your one application.

Consider that CPU is switching amongst four applications ( four processes ) and uses a time slicing algorithm of some sort to assign some minimal time to each application. If your application did not support user created multiple threads and if the main thread invoked a time consuming function that is say waiting on an IO operation, the CPU would probably switch the application that is currently executing. So your application gets less CPU time though it could have gotten more CPU time had it been a multi-threaded application.

The CPU's switch amongst various processes and threads is so fast that even though only one thread might be executing ( regardless of whether this code synchronizes access on shared data ) at a time, you get a better throughput because of the CPU switches and an impression that the processor is working on things concurrently.

Threads that have too much synchronization overhead may defeat the the very purpose of why people would opt for multi-threaded applications in some cases. But those are really very-very complex applications we are talking about.

Chan
 
Chan Ag
Rancher
Posts: 1090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And also like Winston mentioned in your previous post, even in the case of threads that are synchronizing on shared data, synchronization is usually brief and focused to allow maximum concurrency. So good multi-threaded implementations would strive to get maximum concurrency while still minimizing/eliminating the need to synchronize.

Chan.
 
manish ghildiyal
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...so I am a bit confused here.

Going with I/O stuff, so if one thread is doing a time consuming IO operation, JVM would
switch to another thread in our application. But if this happens then IO operation is suspended,and would be revived only
when JVM switches back to that thread which was excuting IO operation. So this IO thread would then restart where it left,
and then try to complete its pending task, though JVM may find it better to switch to another thread in between....thus this switching goes
on till IO operation is over. So where do we get concurrency here, which I basically understand to be a behaviour when
one thread is doing its stuff(like IO operation in our case) and at SAME TIME other threads are doing their tasks, thus needing
no switching by JVM and when a thread has completed its task it is removed from list of running threads and JVM has no more
to worry about it.
May be I am not getting the basics right here.


Manish
 
Tony Docherty
Bartender
Posts: 3271
82
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I explained in my earlier thread if there is only one processor and one core you can't get true concurrency but it can appear to the user that things are happening concurrently.
Regarding the I/O example you gave, what you have to remember is it is likely that the processor will be processing the I/O data much faster than the data can be transmitted to it and so it will be stopping regularly waiting for the next chunk of data to arrive. During those wait periods a multi-threaded application can switch to a thread that has work to do such as a GUI thread or processing a second I/O stream.
 
manish ghildiyal
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Tony, things are more clear now.

Manish
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!