Re: Visual mauve test?

[Robert Lougher]

On Sat, 25 Dec 2004 11:49:12 +0100, Thomas Zander <address@hidden> wrote:
> Hi Robert,
> thanks for looking into this;
>

No problem.  It was quite interesting.
 
> 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.

If you are using this lock object in both threads in the same places,
then you've just replaced one lock with another :)  I also think you
should realise that I'm not talking about a hypothetical deadlock
situation here.  I debugged it using gdb, following each thread's Java
and C stack, and inspecting the thread and monitor states.

> I'm also quite sure that a synchronized method on
> class Foo is different from doing synchronized(foo) outside of the class.

If foo is an instance of Foo and the method is an instance method then
the two are exactly the same (see section 8.4.3.6 of the Java Language
Specification 
http://java.sun.com/docs/books/jls/second_edition/html/classes.doc.html#260369).
 The fact that it is "outside" of the class makes no difference.

> Vector is not really thread safe, you know :)

I believe this mostly concerns Enumerations over the Vector, as they
aren't fail-fast (unlike Iterators).  Anyway, in this case, add calls
addElement which is synchronised, and the other thread is in a
synchronised block on the same object.

Rob.

> 
> 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
>