What's the correct way to run a code in the EDT only once?

Question

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?

Answer 1

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
        ...
    }

Answer 2

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.");
  }
}

Answer 3

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