CODEWITHSUNDEEP
javaandroidmultithreadingthreadpoolandroid-volley
davidvarghese
davidvarghese

Reputation: 677

What is the overhead of a waiting thread?

I am working with Volley library in android for Http communications . By default volley library is keeping 4 threads which take http 'Request' objects(Request object contains all those details for making an http request like url,http method,data to be posted etc) from a BlockingQueue and make http requests concurrently . When I analyze my app requirement, only below 10% of time I will be using the all 4 threads at a time , and rest of the time I will be using 1 or 2 threads from that thread pool. So in effect 2 to 3 threads will be at wait() mode almost 90% of the time .

So here is my question, 1) What is the overhead of a thread which is in wait() mode , does it consume a significant amount of cpu cycles? and is it a good idea for me to keep all those threads in wait.

I assume that since a waiting thread will be continuously checking on a monitor/lock in a loop or so(internal implementation) to wake up ,it might consume a considerable amount of cpu cycles to maintain a waiting thread . Correct me if I am wrong.

Thanks .

Upvotes: 4

Views: 2701

Answers (1)

G. Demecki
G. Demecki

Reputation: 10586

  1. What is the overhead of a thread which is in wait() mode

None. Waiting thread doesn't consume any CPU cycles at all, it just waits for being awakened. So don't bother yourself.

  1. I assume that since a waiting thread will be continuously polling on a monitor/lock internally to wake up ,it might consume a considerable amount af cpu cycles to maintain a waiting thread . Correct me if I am wrong.

That's not true. A waiting thread doesn't do any polling on a monitor/ lock/ anything.

The only situation where a big number of threads can hurt performance is where there is many active threads (much more than nr of CPUs/ cores) which are often switched back and forth. Because CPU context switching also comes with some cost. Waiting threads only consumes memory, not CPU.

If you want to look at the internal implementation of threads - I have to disappoint you. Methods like wait()/ notify() are native - which means that their implementation depends on the JVM. So in case of the HotSpot JVM you can take a look at its source code (written in C++/ with a bit of the assembler).

But do you really need this? Why you don't want to trust a JVM documentation?

Upvotes: 5

Related Questions