Linux threads waiting forever

[Francis Pallini]

Hello,

I am getting angry because it seems that thread synchronization
implementation of Sun under Linux is not reliable and I would like
your opinion. Maybe I am doing something wrong, something huge I don't
see.

I am using Sun JVM 1.4.2_03 (RedHat 9 up-to-date, server JVM mode,
1024 MB heap but at most 256 MB used) and I get threads waiting
forever. The following snippets come from a Java server application:

public void run() {
synchronized (this) {
try {
while (true) {
[...]
// Wait until the pool wakes up the thread or interrupts it
log.debug("Sleep...");
wait();
log.debug("Woken up!");
[...]
}
} catch (InterruptedException ie) {
// Stop thread
log.debug("Interrupted");
return;
}
}
}

public synchronized void run(Runnable target) {
log.debug("Wake up thread (" + getName() + ")");

if (target == null) {
throw new IllegalArgumentException("Null target");
}

this.target = target;
notifyAll();
}

This snippets show the only two "this" object monitor management
functions (nothing usefull hidden). Then excerpts from the log:

2004-02-27 09:59:58,738 DEBUG [Thread-8] PoolableThread:45 - Sleep...
[... nothing more about Thread-8 for two hours, then ...]
2004-02-27 11:59:34,239 DEBUG [Thread-0] PoolableThread:74 - Wake up
thread (Thread-8)
[... and then nothing else happens ...]

At this point, "Thread-8" even stops responding to interrupt calls. It
is lost in cyberspace (or elsewhere).

Any ideas will be very welcome. Is it possible that "wait" throws
undocumented exceptions? Please note that such problems don't araise
under Windows.

Best regards,

Francis PALLINI

 

[Steve Horsley]

Hello,

I am getting angry because it seems that thread synchronization
implementation of Sun under Linux is not reliable and I would like
your opinion. Maybe I am doing something wrong, something huge I don't
see.

I am using Sun JVM 1.4.2_03 (RedHat 9 up-to-date, server JVM mode,
1024 MB heap but at most 256 MB used) and I get threads waiting
forever. The following snippets come from a Java server application:

public void run() {
synchronized (this) {
try {
while (true) {
[...]
// Wait until the pool wakes up the thread or interrupts it
log.debug("Sleep...");
wait();
log.debug("Woken up!");
[...]
}
} catch (InterruptedException ie) {
// Stop thread
log.debug("Interrupted");
return;
}
}
}

public synchronized void run(Runnable target) {
log.debug("Wake up thread (" + getName() + ")");

if (target == null) {
throw new IllegalArgumentException("Null target");
}

this.target = target;
notifyAll();
}

This snippets show the only two "this" object monitor management
functions (nothing usefull hidden). Then excerpts from the log:

2004-02-27 09:59:58,738 DEBUG [Thread-8] PoolableThread:45 - Sleep...
[... nothing more about Thread-8 for two hours, then ...]
2004-02-27 11:59:34,239 DEBUG [Thread-0] PoolableThread:74 - Wake up
thread (Thread-8)
[... and then nothing else happens ...]

At this point, "Thread-8" even stops responding to interrupt calls. It
is lost in cyberspace (or elsewhere).

Any ideas will be very welcome. Is it possible that "wait" throws
undocumented exceptions? Please note that such problems don't araise
under Windows.

Best regards,

Francis PALLINI

Are these two methods from the same class? If not then you have a problem.

run() waits until someone notifies THIS object.
run(Runnable) notifies THIS object.

You may be making the mistake of notifying the wrong object.

So assuming that both methods belong to the same object, one thread
will get stuck in run(), and a different thread must call
run(Runnable) to wake it. This is OK except that if the run() method
is busy (not waiting) any other thread trying to give it a Runnable
will block until the current job is finished. Which may not be
the way you intended the design to work.

Steve

 

[Francis PALLINI]

Hello Steve,

You're right to stress that point. Actually, another objet (ThreadPool) is
doing the mediation between PoolableThread (I shown a part of its code) and
its potential users. Before going to sleep, "Thread-8" (in my example) adds
itself to a synchronized list of available threads. Then, it sleeps
(actually, it "waits" and releases the monitor of "this") and the monitor of
"this" becomes available to other threads (run(Runnable) is synchronized on
that monitor).

Nevertheless, we changed our JVM from Sun to IBM. It seems now that it works
fine (a little bit too early to be sure). The only problem we encounter at
this time with IBM's JVM is their implementation of JSSE (broken with SSLv3
and OpenSSL as client peer). We had to replace it with Sun's one (we still
have to check the license about this point) and it worked fine. Also, memory
consumption is much higher, but too early to point leaks or garbage
collection differences.

Best regards,

Francis PALLINI