The moose likes Threads and Synchronization and the fly likes Runnable state Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Runnable state" Watch "Runnable state" New topic

Runnable state

Pradeep nayar

Joined: Aug 01, 2008
Posts: 3
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

Joined: Sep 28, 2004
Posts: 20514

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.


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028
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

Joined: Aug 01, 2008
Posts: 3

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

Joined: Aug 01, 2008
Posts: 3
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
[ August 03, 2008: Message edited by: Pradeep nayar ]
I agree. Here's the link:
subject: Runnable state
It's not a secret anymore!