I just found out that jdk 1.6 13+ they changed it so that
countComponents does NOT lock the AWTTreeLock now.
Probably a good idea to review all threaded calls to any AWT/Swing
parent component methods *in case* they change the locking mechanism.
-----Original Message-----
From: Don Dietrick [mailto:dietrick_at_bbn.com]
Sent: Wednesday, May 06, 2009 10:27 AM
To: Newcomb, Michael-P57487
Cc: openmap-users_at_bbn.com
Subject: Re: [OpenMap Users] Deadlock with newer versions of jdk 1.6
Hi Michael,
Thanks for the heads-up, sounds like we'll have to change the locks.
- Don
On May 5, 2009, at 1:23 PM, Newcomb, Michael-P57487 wrote:
> The latest versions of jdk 1.6 (with at least update 11+) have changed
> some AWT methods that cause deadlock with OpenMap.
>
> When DTEDWorker finishes, it:
> 1. calls workerComplete(), which locks the DTEDLayer 2. calls
> repaint() 3. repaint() snakes its way up to
> BufferedLayer.BLMapBean.repaint() 4. that calls hasLayers() which in
> turn calls countComponents()
>
> Container.countComponents(), sometime between update 7 and update 11,
> changed to actually go through and count the components instead of
> returning a cached size. This locks the AWTTreeLock and causes a
> deadlock with normal repaint() code coming down and locking the
> AWTTreeLock.
>
> Normal paint():
> 1. locks AWTTreeLock as it is painting it's children 2. calls
> DTEDLayer.paint() 3. which calls getGraphicsList() which locks the
> DTEDLayer
>
> So, the deadlock occurs when the AWT thread locks the AWTTreeLock and
> *then* tries to lock the DTEDLayer object on getGraphicsList().
> But the DTEDWorker locks the DTEDLayer *then* tries to lock the
> AWTTreeLock.
>
> I don't think this will be isolated to DTEDLayer because I think there
> are patterns like this all throughout OpenMap.
>
> Thanks,
> Michael
>
--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Wed May 06 2009 - 10:53:52 EDT