On Feb 1, 2008, at 4:07 PM, Dave Glowacki wrote:
I seem to have turned up a race condition in the ThreadPool class.
I was running the latest xmlrpc (from Subversion) under the JRockit
JVM on a multicore machine and the XML-RPC server was locking up.
I eventually tracked it down to these two bits of code:
public void run() {
while (!isShuttingDown()) {
final Task t = getTask();
if (t == null) {
try {
synchronized (this) {
wait();
}
and:
synchronized void start(Task pTask) {
task = pTask;
synchronized (thread) {
thread.notify();
}
}
The first bit of code is run by a newly created thread, while the
second bit of code is run in the original thread. As far as I can
tell, JRockit did the following:
1) the new Thread started up, called getTask() and got back null.
2) the original thread ran the entire start() method, assigning
'task' and calling thread.notify()
3) the new Thread then entered the 'synchronized' block and did the
wait(), but since the notify() was already called, it never wakes up
I've attached a patch which fixed the problem for me.<xml.patch>
Actually, further testing reveals that my "fix" is susceptible to a
deadlock. I'll try to come up with a better fix...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
