FULL PRODUCT VERSION :
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Calls to BlockingQueue.take() should block when the queue is empty.  When using a BlockingQueue from two threads (one producer, one consumer), the consumer thread busy-waits (spins up to 100% CPU) after the producer thread has died.  The consumer thread should block and the cpu should be idle after the producer thread has died.

Problem may be within call to java.util.concurrent.locks.ReentrantLock.ConditionObject.await()

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See attached testcase, also described below:

Create a BlockingQueue (behaviour seen with both LinkedBlockingQueue and ArrayBlockingQueue).
Start a thread that loops forever calling BlockingQueue.take().
Start another thread that calls BlockingQueue.put(new Object()) once then exits.
Watch cpu usage rise to 100%
Observe thread-dump showing consumer thread in tight-looping 'runnable' state.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Consumer thread should become blocked or descheduled, cpu usage should drop to zero.
ACTUAL -
Consumer thread busy-waits in tight loop, cpu usage rises to 100% until JVM is forcibly shutdown.

Thread dump:
Full thread dump Java HotSpot(TM) Client VM (1.5.0-beta-b32c mixed mode):

"DestroyJavaVM" prio=5 tid=0x00237ca8 nid=0x884 waiting on condition [0x00000000..0x0006fae8]

"Thread-0" prio=5 tid=0x00a43478 nid=0x880 runnable [0x014cf000..0x014cfd64]
	at java.lang.Thread.isInterrupted(Native Method)
	at java.lang.Thread.interrupted(Thread.java:797)
	at java.util.concurrent.locks.ReentrantLock$ConditionObject.await(ReentrantLock.java:1400)
	at java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:345)
	at tmp.BlockingQueueThreadTest$1.run(BlockingQueueThreadTest.java:13)
	at java.lang.Thread.run(Thread.java:566)

"Monitor Ctrl-Break" daemon prio=5 tid=0x00a3f768 nid=0x860 runnable [0x0139f000..0x0139f9e4]
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:129)
	at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408)
	at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450)
	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182)
	- locked <0x6ddc1858> (a java.io.InputStreamReader)
	at java.io.InputStreamReader.read(InputStreamReader.java:167)
	at java.io.BufferedReader.fill(BufferedReader.java:136)
	at java.io.BufferedReader.readLine(BufferedReader.java:299)
	- locked <0x6ddc1858> (a java.io.InputStreamReader)
	at java.io.BufferedReader.readLine(BufferedReader.java:362)
	at com.intellij.rt.execution.application.AppMain$1.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:566)

"Low Memory Detector" daemon prio=5 tid=0x009cbca0 nid=0x874 runnable [0x00000000..0x00000000]

"CompilerThread0" daemon prio=10 tid=0x009ca8e8 nid=0x858 waiting on condition [0x00000000..0x00f8f854]

"Signal Dispatcher" daemon prio=10 tid=0x0023fb48 nid=0x864 waiting on condition [0x00000000..0x00000000]

"Finalizer" daemon prio=9 tid=0x00994588 nid=0x840 in Object.wait() [0x00d8f000..0x00d8fc64]
	at java.lang.Object.wait(Native Method)
	- waiting on <0x6dd705d0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
	- locked <0x6dd705d0> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x009c9a08 nid=0x854 in Object.wait() [0x00c8f000..0x00c8fce4]
	at java.lang.Object.wait(Native Method)
	- waiting on <0x6dd704a0> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:468)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:118)
	- locked <0x6dd704a0> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x00993120 nid=0x528 runnable

"VM Periodic Task Thread" prio=10 tid=0x009cceb0 nid=0x794 waiting on condition


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.BlockingQueue;

public class BlockingQueueThreadTest {
    public static void main(String[] args) {
        final BlockingQueue queue = new ArrayBlockingQueue(10);
        Thread consumer = new Thread(new Runnable() {
            public void run() {
                while (true) {
                    try {
                        queue.take();
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        });

        consumer.start();

        launchProducer(queue);
    }

    private static void launchProducer(final BlockingQueue queue) {
        Thread worker = new Thread(new Runnable() {
            public void run() {
                try {
                    queue.put(new Object());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
        worker.start();
    }
}

---------- END SOURCE ----------
(Incident Review ID: 244303) 
======================================================================

N/A

I can reproduce this on Windows 2000 with Tiger b32c, but not with b43 on
either solaris-sparc or Windows 2000.

It appears that this bug has been fixed in a recent Tiger beta.

I intend to close this as "not reproducible".

  xxxxx@xxxxx   2004-03-22