Found one Java-level deadlock:
=============================
"AWT-EventQueue-0":
   waiting to lock monitor 0x008101cc ( customer  0x105128f8, a java.util.ArrayList),

   which is held by "Java Sound event dispatcher"
"Java Sound event dispatcher":
   waiting to lock monitor 0x008101ac ( customer  0x1050da70, a com.sun.media.sound.H
eadspaceMixer),
   which is held by "AWT-EventQueue-0"

Java stack information for the threads listed above:
===================================================
"AWT-EventQueue-0":
         at com.sun.media.sound.EventDispatcher.autoClosingClipOpened(EventDispatcher.java:447)
         - waiting to lock <0x105128f8> (a java.util.ArrayList)
         at com.sun.media.sound.MixerClip.open(MixerClip.java:166)
         - locked <0x1050da70> (a com.sun.media.sound.HeadspaceMixer)
         at com.sun.media.sound.JavaSoundAudioClip.startImpl(JavaSoundAudioClip.java:143)
         - locked <0x10520310> (a com.sun.media.sound.JavaSoundAudioClip)
         at com.sun.media.sound.JavaSoundAudioClip.play(JavaSoundAudioClip.java:120)
         - locked <0x10520310> (a com.sun.media.sound.JavaSoundAudioClip)
         at sun.applet.AppletAudioClip.play(AppletAudioClip.java:194)
         - locked <0x10516ae8> (a sun.applet.AppletAudioClip)
         at Wall.processBallMovement(Wall.java:140)
         at Ball.notifyListeners(Ball.java:76)
         at Ball.actionPerformed(Ball.java:57)
         at javax.swing.Timer.fireActionPerformed(Timer.java:271)
         at javax.swing.Timer$DoPostEvent.run(Timer.java:201)
         at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:454)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:208)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:151)

         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:143)

         at java.awt.EventDispatchThread.run(EventDispatchThread.java:104) "Java Sound event dispatcher":
         at com.sun.media.sound.AbstractDataLine.close(AbstractDataLine.java:414)

         - waiting to lock <0x1050da70> (a com.sun.media.sound.HeadspaceMixer)
         at com.sun.media.sound.EventDispatcher.closeAutoClosingClips(EventDispatcher.java:430)
         - locked <0x105128f8> (a java.util.ArrayList)
         at com.sun.media.sound.EventDispatcher.dispatchEvents(EventDispatcher.java:339)
         at com.sun.media.sound.EventDispatcher.run(EventDispatcher.java:374)
         at java.lang.Thread.run(Thread.java:534)


> I don't have a test case yet, but I can see the deadlock in the code,
> from tracing the info in the trace below.
> 
> JavaSoundAudioClip does this:
>         clip.open()
> which calls MixerClip.open(), which does this:
>         synchronized (mixer) {
>                 getEventDispatcher().autoClosingClipOpened(this);
>         }
> and EventDispatcher().autoClosingClipOpened(this) does this:
>         synchronized (autoClosingClips) {
>                 ...
>         }
> where audioClips is an ArrayList()  customer .
> 
> Meanwhile, on the Event Dispatching thread, we call:
>         closeAutoClosingClips(), which does this:
>         synchronized (audioClosingClips) {
>                 clip.close();
> where close() is in AbstractDataLine:
>         public void close() {
>                 synchronized (mixer) {
>                         ...
> 
> and voila, DEADLOCK.
> The first thread above grabs the mixer and then tries to lock
> the audioClips  customer .  Meanwhile, the dispatch thread grabs the
> audioClips  customer  and then tries to lock the mixer.
> 
> The fix must involve somehow guaranteeing that these threads cannot
> be doing these things at the same time or that the objects they
> are locking (mixer and audioClips) cannot be locked out of order.
> 
> I wonder if the call to:
>         getEventDispatcher().autoClosingClipOpened(this);
> above is correct?  That is, do we really want to execute this
> dispatcher method on the current thread, or do we want to tell the
> dispatcher to execute this call on the dispatcher thread?  If we
> put it on the dispatcher thread, then this deadlock is avoided because
> the dispatcher thread cannot deadlock with itself.

> I realized that my app was actually doing rendering (and thus
> calling AudioClip.play()) from 2 distinct threads.  I tweaked
> the SoundDeadlock app to do the same thing (issue plays from
> 2 different threads), but I still haven't seen the deadlock there.
> Maybe there's just a really small window where this deadlock can
> occur and it's just a (small) random chance that it'll crop up.



======================================================================

N/A

  xxxxx@xxxxx   2003-08-26
	Not yet investigated. Clip's stability is very important for many apps and applets.

  xxxxx@xxxxx   2003-10-01
not reproduced by running, but verified the theoretical possibility.
The Line base classes are a mess, so it is likely that there are still other bugs of this sort.