[concurrency-interest] Confused about Component.getTreeLock()

David Holmes dcholmes at optusnet.com.au
Tue Mar 6 06:56:09 EST 2007


The AWT was intended to be multi-threadsafe and does not enforce the
"everything must happen in the event thread rule". That was a mistake that
Swing rectified. So many of the AWT components use locks and the
component-tree uses the TreeLock. The problem with the tree-lock is that its
client--side synchronzation (all clients have to know when they should
acquire it) and yet there is no documentation telling clients when they need
to acquire it.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> Kovacs
> Sent: Tuesday, 6 March 2007 9:23 PM
> To: concurrency-interest
> Subject: [concurrency-interest] Confused about Component.getTreeLock()
> Hi,
> >From samples found on the Internet I can see that the
> Component.getTreeLock() method is mainly used in custom layout
> managers. Doesn't the assumption implied by the use of this lock go
> against the general rule that Java graphical components should not be
> manipulated from a thread other than the AWT Event Handler? In other
> words: why are layout management functions likelier to be executed in
> a custom thread -- a situation where locking is required at all --
> than are other kinds of GUI functions?
> Thanks
> Peter
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list