File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Runnable state

 
Pradeep nayar
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a java program which has threads that connects to a TCP server and tries to do a blocking read on the socket.
The server is not sending anything on the sockets
I was seeing all these threads on the profiler and saw all these threads showed as RUNNING
Did a thread dump to find that these threads are in RUNNABLE state.

On a blocking read on the socket( basically waiting for network I/O) the thread state should be BLOCKED or WAITING right?

Instead when they show up as RUNNABLE, this means that cpu time slices are being wasted on this thread?
 
Henry Wong
author
Marshal
Pie
Posts: 20823
75
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, it depends. Doing a blocking read doesn't mean that it should always be in an IO wait state. It will be in a running state when IO is actually being read, and the thread is processing stuff.

There is not enough detail in the question to speculate why your threads are mostly in the runnable state.

Henry
 
Mike Simmons
Ranch Hand
Posts: 3028
10
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A couple years ago I tested Thread.getState() in various IO blocking situations, and I found that it seemed that some IO classes never come up WAITING or BLOCKED, while others use those frequently. At the moment I don't remember which classes did which.

I think this may be implementation-dependent. Many IO classes rely on native methods, and those methods have ways to block without wasting machine cycles, but also without using Java's synchronization or wait() method. The problem of having a process block until an IO device is ready existed long before Java, after all, and solutions were found. So from the JVM's perspective, those methods may always show up as RUNNABLE or RUNNING, never WAITING or BLOCKED - even though they are, in fact, blocking, in a wider (non-Java-threads) sense of the term. Meanwhile some other implementations (or other IO classes entirely) may use WAITING or BLOCKED just as you'd expect.

You may be able to tell from the source code - if a class explicitly uses synchronized blocks, wait(), and/or java.util.concurrent techniques, then you can expect to see WAITING or BLOCKING as states. But if the class does most work in native methods, you can't tell without looking at that native code (which is generally harder to find and understand, and in some cases completely unavailable) - and there's a very good chance that the native methods did not rely on Java's threading utilities.
[ August 03, 2008: Message edited by: Mike Simmons ]
 
Pradeep nayar
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Henry,

You are right about that. But in my case, the server is not sending anything over, even then it the thread which is blocked on socket read shows up as in RUNNABLE state. I know you might be wondering what I am trying to do here..
I wrote this small program to simulate what a real world application at work was doing, while trying to identify bottlenecks.
The application that i am talking about opens a reader and writer thread each for every new socket connection opened. There are other threads running in the application for other purposes as well.What I have observed is this is not a scalable way of handling connections.With almost 1000 threads around in a deployment scenario , the time taken between the all the context switches could slow things down and causing thread starvation for one thread. While trying to figure this out, saw the threads which are on blocked read calls shown up as RUNNABLE state. After all the exploration on this topic, I think way to go would be with threadpools and NIO
[ August 03, 2008: Message edited by: Pradeep nayar ]
 
Pradeep nayar
Greenhorn
Posts: 3
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the answer Mike, I agree it should definitely be a mismatch of reporting the states between JVM and the underlying native implementations.
I will try to see what the underlying code for this class does
Thanks
Pradeep
[ August 03, 2008: Message edited by: Pradeep nayar ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic