4

I have a Swing application that uses a Java Thread to constantly perform some operation. The results of this operation update the contents of a graph in the UI:

class ExampleThread {
    ... 
    public void run() {
        while (running) {
            // extract some information
            ...

            // show results in UI
            SwingUtilities.invokeLater(new Runnable() {
                public void run() {
                     // use information to update a graph
                }
            });

            // sleep some seconds
            ...
        }
    }
    ...
}

The problem that I am having is when the EDT is bloated in other operations. In this case, the ExampleThread may register various Runnable instances that update the graph. For my application, it will be a waste of time since the graph will be updated several times before showing the results. What I would like is to run the //update a graph code at most once per EDT cycle.

My question is: what is the proper way to ensure that a Runnable is run only once?

Lii
  • 11,553
  • 8
  • 64
  • 88
YuppieNetworking
  • 8,672
  • 7
  • 44
  • 65

3 Answers3

5

An atomic dirty flag should do the trick. This has the added benefit of only adding to the EDT queue if necessary. Big assumption - your data structure(s) holding the extracted information are thread safe, but that would have to be true for your code above to work correctly as well. If they aren't you should consider the SwingWorker approach indicated in the other answer; you also could combine with the dirty flag to prevent redundant updates.

AtomicBoolean dirty = new AtomicBoolean(false);
while (running) {
        // extract some information
        ...

        if (!dirty.getAndSet(true)) {            
          SwingUtilities.invokeLater(new Runnable() {
              public void run() {
                if (dirty.getAndSet(false)) {
                   // use information to update a graph
                }
              }
          });
        }

        // sleep some seconds
        ...
    }
Scott A Miller
  • 696
  • 5
  • 9
  • You don't need an explicit flag; you simply need to check whether your data structure (e.g. queue) is empty before adding a new item to it. If it is empty then this is an indicator that the EDT requires scheduling again. – Adamski Nov 16 '10 at 16:43
  • 1
    True - although it depends on the data structure. I was assuming as little as possible; he might not have a queue of update objects, but rather a global state that was being modified and rendered. I was trying to provide the least intrusive solution to his code above while solving the question. Generally speaking, I take the SwingWorker approach as well. – Scott A Miller Nov 16 '10 at 16:58
3

I suggest using a SwingWorker and taking advantage of the publish method to publish updates back onto the EDT. The EDT will then apply one or more updates when it is next scheduled. For example, suppose your calculation result are Integer instances:

// Boolean flag to determine whether background thread should continue to run.
AtomicBoolean running = new AtomicBoolean(true);

new SwingWorker<Void, Integer>() {
  public Void doInBackground() {
    while (running.get()) {
      // Do calculation
      Integer result = doCalculation();

      publish(result);
    }
  }

  protected void process(List<Integer> chunks) {
    // Update UI on EDT with integer results.
  }
}

An alternative approach is to create a single Runnable instance that simply consumes from a Queue of results each time it is scheduled. This is similar to how SwingWorker operates under the covers but gives you slightly more control in that you can control the Queue implementation and avoid permanently holding one of the SwingWorker pooled threads.

private final Queue<Integer> resultQueue = Collections.synchronizedList(new LinkedList<Integer>());
// Thread-safe queue to hold results.    

// Our re-usable Runnable to be run on the EDT.  Consumes all results from the result queue
// before releasing the lock, although could obviously change this to consume up to N results.
Runnable consumer = new Runnable() {
  public void run() {
    synchronized(resultQueue) {
      Integer result;

      while ((result = resultQueue.take()) != null) {
        // Update UI.
      }
    }
  }
}

...

// Business logic to run on background thread.  Conditionally schedules the EDT to run as required.
while (true) {
  Integer result = doCalculation();

  synchronized(resultQueue) {
    boolean scheduleEdt = resultQueue.isEmpty();
    // Queue was empty before this result is added so need to schedule the EDT to run again.

    resultQueue.add(result);
  }

  if (scheduleEdt) {
    SwingUtilities.invokeLater(consumer);
  } else {
    System.err.println("EDT already scheduled -> Avoiding unecessary reschedule.");
  }
}
Adamski
  • 54,009
  • 15
  • 113
  • 152
  • There is no need for SwingWorker. Writing own lightweight classes is sufficient. – Mot Nov 16 '10 at 16:03
  • @mklhmnn: What is "heavyweight" about using SwingWorker? This is exactly the type of situation it was designed for. You'll see I've provided an alternative home-grown solution, which results in less compact code. – Adamski Nov 16 '10 at 16:12
  • SwingWorker is generally the best way to go for working between background threads and the EDT. I'm not sure how the above solves the redundant updates issue, though. – Scott A Miller Nov 16 '10 at 16:16
  • I forgot to mention that I am stuck with JDK5. The first option seems like the way to go in this case. I thought that maybe there was a feature unknown to me that did this out of the box. – YuppieNetworking Nov 16 '10 at 16:25
  • Maybe I misunderstood the question? I thought you were trying to prevent multiple redundant calls to update the UI. The first option above will call the process method for every update, which I thought you were specifically trying to avoid. – Scott A Miller Nov 16 '10 at 16:30
  • 1
    @Scott: Each call to publish does not necessarily result in an equivalent call to process: The SwingWorker chunks the results together in exactly the same manner as my homegrown solution using an internal queue. – Adamski Nov 16 '10 at 16:41
  • @Scott: I am sorry, it was me who got it all mixed up – YuppieNetworking Nov 16 '10 at 17:37
0

Alternatively you might want to look into using a javax.swing.Timer.

Qwerky
  • 18,217
  • 6
  • 44
  • 80