Re: Visual mauve test?

[Thomas Zander]

Hi Robert,
thanks for looking into this;

as you say; deadlocks are the first thing you consider in such a case.  And 
I surely tested if my testcase was in error.
I replaced the lock with a dedicated lock object, and still get the 
deadlock;  this makes me think your factoring in the synchronized parts in 
Vector are incorrect.  I'm also quite sure that a synchronized method on 
class Foo is different from doing synchronized(foo) outside of the class.
Vector is not really thread safe, you know :)

If you don't follow my propsed lock object example above; just ask and I'll 
send you the changed class.

Other things:
- why is Swing doing things (painting) on non-showing peers?
- what about making the setVisible(true) less thread-problematic; its true 
the Swing spec says it has to be called in the AWT Thread; but making it 
place one or more events in the AWT queue instead of doing it 'inline' 
would go a long way of solving that problem.
Note that I have not read the classpath-swing sources; I'm deducing this 
from Roberts email.

/me going back to Christmas things now :)

On Saturday 25 December 2004 05:13, Robert Lougher wrote:
> 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

-- 
Thomas Zander