bug-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug awt/30122] Deadlock in Component.getFont()


From: volker dot berlin at goebel-clan dot de
Subject: [Bug awt/30122] Deadlock in Component.getFont()
Date: 8 Dec 2006 21:37:03 -0000


------- Comment #3 from volker dot berlin at goebel-clan dot de  2006-12-08 
21:37 -------
(In reply to comment #1)
> I strongly disagree. This methods depends on the tree not beeing messed around
> with and thus should be synchronized on the tree lock.
> 
> If you could please make a testcase that shows the deadlock I'm happy to help
> with solving the problem.
> 

If you think that a get method shold be synchronized on getTreeLock() then you
should synchronized all get method that scroll through the hierachie like
getBackGround() or getForeGround(). Currenlty only getFont is synchronized.

A Test Sample:
With the latest IKVM version the follow line produce the deadlock:
new Frame().show()
If this line call on a main thread.

The show() is calling addNotify() this is synchronized on getTreeLock(). This
is correct. addNotify() is creating the peer. To creating the peer there is a
thread switch to the event thread. Then the event thread create the peer in
IKVM. Now should the peer init with the status of the component like font,
size, color, etc. This values can only set in the event thread but request can
I the values only in caller thread.

One solution is to make approx 10 thread switch on creating the peer but this
will consume many time.

The problem can't solv with changes the call order both synchronized are in AWT
on one object. But there are 2 threads that wait on the other.

If you does not change this then I must search another solution.

Volker

PS: The Sun VM has also no synchronized on this point.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30122





reply via email to

[Prev in Thread] Current Thread [Next in Thread]