Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.gui > #3867 > unrolled thread

Worker Threads and EDT

Back to article view | Back to comp.lang.java.gui

Contents

  Worker Threads and EDT "i.dont.need" <i.dont.need@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
    Re: Worker Threads and ED "tar" <tar@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
      Re: Worker Threads and ED "i.dont.need" <i.dont.need@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
      Re: Worker Threads and ED "Roedy Green" <roedy.green@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
        Re: Worker Threads and ED "jlp" <jlp@THRWHITE.remove-dii-this> - 2011-04-27 15:48 +0000
    Re: Worker Threads and ED "Larry A Barowski" <larry.a.barowski@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
      Re: Worker Threads and ED "i.dont.need" <i.dont.need@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000
        Re: Worker Threads and ED "Larry A Barowski" <larry.a.barowski@THRWHITE.remove-dii-this> - 2011-04-27 15:47 +0000

#3867 — Worker Threads and EDT

  To: comp.lang.java.gui

I have some legacy code to spruce up, and it breaks one of the cardinal 
rules of swing: it updates the UI with worker threads (not the EDT). 
Finding all of the potential culprits is easy, but there are hundreds of 
cases which could be problematic, and the vast majority are fine. It is 
quite difficult to determine via inspection whether or not a specific 
worker thread will cause problems because dependencies back to the UI 
are typically routed through at least one interface, one or more 
abstract classes and a chain of one or more listeners (business objects 
expose a generic property change event, and all manner of things 
register for notifications). How can I figure out which threads have a 
transitive dependency back to some UI object? I could easily name worker 
threads, but the problems typically manifest themselves on the EDT in 
the various paint methods. Is there any way I could instrument the code 
so that in development, I could throw an exception any time a component 
is touched by a thread other than the EDT?

--
Shane

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [next] | [standalone]

#3868 — Re: Worker Threads and ED

  To: comp.lang.java.gui
i.dont.need@any.more.email writes:

> I have some legacy code to spruce up, and it breaks one of the
> cardinal rules of swing: it updates the UI with worker threads (not
> the EDT). Finding all of the potential culprits is easy, but there are
> hundreds of cases which could be problematic, and the vast majority
> are fine. It is quite difficult to determine via inspection whether or
> not a specific worker thread will cause problems ... How can I figure
> out which threads have a transitive dependency back to some UI object?

Well, what sorts of actions does the application take in connection with
the EDT?

If you know what types of manipulation are being done, then you may be
able to instrument just the places where those sorts of things happen,
such as creating new windows, updating the state of controls, etc.

You could insert something like:

  assert SwingUtilities.isEventDispatchThread();

in the places where UI elements are created, modified or manipulated and
see where any errors pop up.  You would need to make sure you enabled
assertion checking for the development phase.


> Is there any way I could instrument the code
> so that in development, I could throw an exception any time a component
> is touched by a thread other than the EDT?

I was working on one project where they had some such instrumentation,
which threw an exception if it thought something was doing GUI work on a
thread other than the EDT.  But I don't recall what was done to achieve
this.  But there is something out there.


-- 
Thomas A. Russ,  USC/Information Sciences Institute

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#3872 — Re: Worker Threads and ED

  To: comp.lang.java.gui
Thomas A. Russ wrote:
> i.dont.need@any.more.email writes:
> 
>> I have some legacy code to spruce up, and it breaks one of the
>> cardinal rules of swing: it updates the UI with worker threads (not
>> the EDT). Finding all of the potential culprits is easy, but there are
>> hundreds of cases which could be problematic, and the vast majority
>> are fine. It is quite difficult to determine via inspection whether or
>> not a specific worker thread will cause problems ... How can I figure
>> out which threads have a transitive dependency back to some UI object?
> 
> Well, what sorts of actions does the application take in connection with
> the EDT?

I'm not altogether sure what you're asking here.


> If you know what types of manipulation are being done, then you may be
> able to instrument just the places where those sorts of things happen,
> such as creating new windows, updating the state of controls, etc.

Hmm... I kinda get where you're going, but a priori, I don't really know 
what is causing the problem. Updating the state of controls is 
definitely an issue, but which controls? There are boatloads of 
possibilities. One place that seems to have high frequency is 
DefaultTableColumnModel.getColumn(int) which gets called from 
BasicTableUI.paintCells. I guess any worker threads pulling out data 
from the db which gets put into to tables is a place to start here. It's 
quite a manual approach, but better than none.


>   assert SwingUtilities.isEventDispatchThread();

I like the simplicity of this, I just wish I could automate it for all 
swing classes rather than have to hunt down all code which interacts 
with the classes I happen to be targeting.


>> Is there any way I could instrument the code
>> so that in development, I could throw an exception any time a component
>> is touched by a thread other than the EDT?
> 
> I was working on one project where they had some such instrumentation,
> which threw an exception if it thought something was doing GUI work on a
> thread other than the EDT.  But I don't recall what was done to achieve
> this.  But there is something out there.

Do you recall any names of classes or tools or techniques you used? 
Googling things related to the EDT or worker threads turns up heaps of 
stuff which is unrelated.

Thanks.

--
Shane

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#3947 — Re: Worker Threads and ED

  To: comp.lang.java.gui
On 01 Aug 2008 14:04:16 -0700, tar@sevak.isi.edu (Thomas A. Russ)
wrote, quoted or indirectly quoted someone who said :

>  assert SwingUtilities.isEventDispatchThread();

In Forth it was fairly easy to insert your own code at the head of any
existing method to help debug.  I think there is a feature in Java now
that lets you pull off something similar.

Someone mentioned it recently when I asked about ways to tell if a
class is already loaded without actually triggering a load.

If you could instrument some of the methods of JComponent, you could
put your assertions there.
-- 

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#4010 — Re: Worker Threads and ED

  To: comp.lang.java.gui
Roedy Green a ocrit :
> On 01 Aug 2008 14:04:16 -0700, tar@sevak.isi.edu (Thomas A. Russ)
> wrote, quoted or indirectly quoted someone who said :
> 
> 
>> assert SwingUtilities.isEventDispatchThread();
> 
> 
> In Forth it was fairly easy to insert your own code at the head of any
> existing method to help debug.  I think there is a feature in Java now
> that lets you pull off something similar.
> 
=> see AspectJ ( aspectj.eclipse.org)  and AOP programming

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#3948 — Re: Worker Threads and ED

  To: comp.lang.java.gui

<i.dont.need@any.more.email> wrote in message 
news:aVJkk.50144$nD.30868@pd7urf1no...
>
> ... Is there any way I could instrument the code so that in development, I 
> could throw an exception any time a component is touched by a thread other 
> than the EDT?

I had this need and ended up using AspectJ to
inject a test before every gui call, using the
following aspect:

aspect ThreadChecker {
   pointcut guiCall():
        (call(* java.awt..*(..)) || call(* javax.swing..*(..))
        || call(java.awt..*.new(..)) || call(javax.swing..*.new(..)))
        && !call(* clone()) && !call(void 
SwingUtilities.invokeLater(Runnable))
        && !call(boolean SwingUtilities.isEventDispatchThread())
        && !call(* javax.swing.text.html.HTMLDocument..*(..));

   before(): guiCall() && !within(ThreadChecker) {
      if (!SwingUtilities.isEventDispatchThread()) {
         System.err.println("Bad gui call:");
         System.err.println(thisJoinPoint.getSourceLocation());
         System.err.println(thisJoinPoint.getSignature());
         System.err.println();
      }
   }
}

You'll probably need some tinkering depending on the
Java version you target and which other thread-safe
gui methods you call (repaint() isn't in the above for
example, but I never call it from outside the EDT and
don't expect to ever need to do so).

It's pretty easy to set up a build to inject that test into
a jar file and merge in the ThreadChecker class and
the AspectJ runtime classes.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#3949 — Re: Worker Threads and ED

  To: comp.lang.java.gui
Larry A Barowski wrote:
> 
> I had this need and ended up using AspectJ to
> inject a test before every gui call, using the
> following aspect:


Thanks, AOP and bytecode injection were the only possibilities that 
sprang to mind, but I had never tried either. At the moment, my 
attention has been diverted to another project, but the 
ThreadCheckingRepaintManager class mentioned earlier has already given 
me something to chew on. When I get back to this issue, I'll give your 
aspect a try too.

--
Shane


> 
> aspect ThreadChecker {
>    pointcut guiCall():
>         (call(* java.awt..*(..)) || call(* javax.swing..*(..))
>         || call(java.awt..*.new(..)) || call(javax.swing..*.new(..)))
>         && !call(* clone()) && !call(void 
> SwingUtilities.invokeLater(Runnable))
>         && !call(boolean SwingUtilities.isEventDispatchThread())
>         && !call(* javax.swing.text.html.HTMLDocument..*(..));
> 
>    before(): guiCall() && !within(ThreadChecker) {
>       if (!SwingUtilities.isEventDispatchThread()) {
>          System.err.println("Bad gui call:");
>          System.err.println(thisJoinPoint.getSourceLocation());
>          System.err.println(thisJoinPoint.getSignature());
>          System.err.println();
>       }
>    }
> }
> 
> You'll probably need some tinkering depending on the
> Java version you target and which other thread-safe
> gui methods you call (repaint() isn't in the above for
> example, but I never call it from outside the EDT and
> don't expect to ever need to do so).
> 
> It's pretty easy to set up a build to inject that test into
> a jar file and merge in the ThreadChecker class and
> the AspectJ runtime classes.
> 
> 
>

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [next] | [standalone]

#3950 — Re: Worker Threads and ED

  To: comp.lang.java.gui

<i.dont.need@any.more.email> wrote in message 
news:4C%nk.126079$kx.82177@pd7urf3no...
> Thanks, AOP and bytecode injection were the only possibilities that sprang 
> to mind, but I had never tried either. At the moment, my attention has 
> been diverted to another project, but the ThreadCheckingRepaintManager 
> class mentioned earlier has already given me something to chew on.

That is simple enough, but it will catch fewer problems than a
check before every gui call.

> When I get back to this issue, I'll give your aspect a try too.

It has worked out great for me. I was converting a debugger
from EDT-only to having a separate, dedicated debugger
thread. So in addition to checking that gui calls only come
from the EDT, I also needed to verify that all JDI calls
come from the debugger thread. The tests also turned up a
few EDT violations in the software that were totally
unrelated to the debugger.

---
 * Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.gui

csiph-web