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

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Wed Mar 7 05:49:13 EST 2007


Gregg,

> ordering controls to make sure that another thread doesn't MESS with the state
> of the components preferredSize()

Do "ordering controls" mean "synchronization" here?

Thanks
Peter

On 3/6/07, Gregg Wonderly <gregg at cytetech.com> wrote:
>
>
> Thomas Hawtin wrote:
> > Gregg Wonderly wrote:
> >> In that case, the component (the JTextField) is realized, so based on
> >
> > No. Even without being realised, documents can post to the EDT in
> > response to be mutated from a non-EDT thread. JTextField has listeners
> > on the object, so is being updated both on and off the EDT, without
> > having been realised.
>
> Okay, I missed that you were referring to the unrealized behavior too.  Yes, a
> setText() call and many others can cause the component to assert the lock as it
> attempts to compute its new preferredSize().  That was a surprising behavior
> change as well.
>
> > Sometimes you need invokeLater even on the EDT. Usually this is down to
> > listeners misbehaving (unfortunately they are often designed to misbehave).
>
> I guess I was not being very clear.  If you read up on JScrollPane, and the
> suggested implementation of calling setPreferredSize() followed by revalidate(),
> it doesn't seem too complicated.  You have to realize/know though that
> revalidate() is using invokeLater() to make its changes take effect, and thus
> you MUST use invokeLater() for any activity that has to happen after the new
> component size takes effect, no matter whether you are running on the EDT at
> that point or not.  In particular, scrolling panes that contain output of some
> sort that you always want to scroll to the end of after the output is added,
> must use invokeLater() to change the scrollbar position, and, they must use
> ordering controls to make sure that another thread doesn't MESS with the state
> of the components preferredSize() while that scroll is being calculated/executed.
>
> >> At the end of the day, it's a tough balancing act.  You want to allow
> >> the application and the EDT to proceed independently, yet to be
> >> synchronized in how they interact with each other.
> >
> > You want to keep a very clear separation between what is EDT and what is
> > not.
>
> As was mentioned earlier, there is very little, if any documentation about what
> separation is actually mandated by the implementation.
>
> Gregg Wonderly
> _______________________________________________
> 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