Skip to Main Content
Forums

Java SE (Java Platform, Standard Edition)

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

when is treelock used?

843804Jan 13 2005 — edited Jan 14 2005
I'm working on a layout manager. I took a look at the source for java.awt.GridBagLayout, and I notice they synchronize on the parent container's treelock. However, it isn't used consistently -- but only within one method.

I would like to know, under which circumstances is required to synchronize on this lock? I would like to understand what it is in GridBagLayout.GetLayoutInfo() that requires this synchronization, as opposed to all other methods which don't synchronize (but operate on the same data structures). Obviously, to answer this question you would have to take a look at the Java source.

I tried searching around:

The javadoc for Container.getTreeLock() says: "Gets this component's locking object (the object that owns the thread sychronization monitor) for AWT component-tree and layout operations." Vague. Doesn't resolve the above question.

http://today.java.net/pub/a/today/2003/08/14/layouts.html. "Synchronizing on the object returned by the container's getTreeLock method ensures thread safety while performing the layout." Still doesn't resolve the above question.

http://forum.java.sun.com/thread.jspa?forumID=5&threadID=11406. Similar question to my own. No answer.

http://forum.java.sun.com/thread.jspa?forumID=5&threadID=9663. Intelligent sounding answer from mtj, but it's a crock. Either way it doesn't resolve the above question.

Etc.

Comments

843804
getTreeLock() is used because multiple threads can create GUI components and do layout on them before show() is called on any of the components. The AWT thread isn't started until show() is called, and after it is started, it's the only thread that's allowed to touch the GUI components.

The lock that is returned is a static final Object within the Component class, so there's only one of them per program.

Does that help?

-Ryan
843804
Does that help?
Actually I am already aware of that. I'm not sure you read my post thoroughly, since your response doesn't address my specific question about why the lock is synchronized on in only one method of GridBagLayout, whereas many of the methods operate on the container and its children. Which is the critical resource being protected in that method? Another poster asked why the lock is not synchronized at all in BoxLayout (see one of the links previously posted).
843804
That is a good question...there are many places that it could be used that it isn't. For instance, if you set a DefaultTableModel's row count to 0 in a thread at the exact moment that the AWTEventQueue Thread is painting your JTable...you can cause an exception...even if you lock onto the treelock. On top of that the exception that appears in System.err won't even have your code listed in it, making it almost impossible to debug easily.

The idea is to synchronize on the treelock whenever you modify a GUI component from another thread. This helps minimize the chance of errors occurring. I think they only put them in there to fix bugs, and not always during development. I have reported bugs before for the IME code, and was able to get their changes to compile on my own...synchronizing on the tree lock.

My guess is that no one has had issues with the BoxLayout, so they haven't had the need to fix anything.
843804
Thanks Rob for your answer. It seems plausible, and I can conceive of no other reason. If it's true, it's not very confidence-inspiring.

I'm going to assume that's the best answer I'll get, and award the dukes.
843804
The original intention of the tree lock was that it was to protect the array of components in a container from being modified concurrently with other operations in the same component tree. Due to a lack of a coherent locking strategy, it has over time turned into a kind of last ditch strategy to fix synchronization bugs within AWT. Essentially it is now just a global AWT lock that papers over bugs from performing AWT operations from off of the EDT.
1 - 5
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Feb 11 2005
Added on Jan 13 2005
#swing
5 comments
481 views