Re: Visual mauve test?

[Robert Lougher]

Hi,

Getting everything out of the way, here's an analysis of the problem below...

I made a standalone version of the testcase.  With this, the problem
only shows up maybe 1 time out of 5, and so it is timing related.  It
is an example of the "classic" deadlock case, where two threads
attempt to obtain the same locks but in a different order.

The first thread is the main thread.  This thread creates the child
JComponent and adds it to the JFrame.  It then synchronises on the
vars Vector and attempts f.setVisible(true).

The second thread is the AWT event thread (AWT-EventQueue-1).  When
the deadlock occurs, it is performing a paint of the newly added
JComponent.  This is called within the paint method of the parent
Container.  Its visitChildren method obtains the AWT tree lock
(getTreeLock()).  Within the child paint method it then attempts to
obtain the lock on the vars Vector (the vars.add calls a synchronised
method).

The AWT event thread is unable to obtain the vars Vector lock because
it is held by the main thread.  The main thread in the meantime is
attempting f.setVisible(true).  This calls getComponents on the
Container, which attempts to obtain the tree lock.  It is unable to
get this lock because it is held by the AWT event thread.  Each thread
is waiting on the other -- neither will release the lock the other is
waiting on, and we therefore have a deadlock.

It is clearly not a bug in JamVM.  Perhaps the tree lock should be
released on calling the child paint method (taking into account
possible changes to the component list on return)?  I am undecided as
to whether the testcase itself is correct.

Rob.

On Mon, 13 Dec 2004 12:44:37 +0100, Thomas Zander <address@hidden> wrote:
> Would anyone have problems with me committing a mauve test that opens a
> Window for a very little time?
> 
> See attached test.
> 
> Next to that; I would like to ask for your expertise to see if I made a
> mistake, or if there is a bug in classpath/jamvm.
> The statement on line 75 (setVisible()) should be inside the synchronized
> block, but if I do that then the frame is properly displayed, but never
> returns.  Putting a System.exit(); before the "try {" line made me sure it
> really never returns.
> 
> Any ideas?
> --
> Thomas Zander
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/classpath
> 
> 
> 
>