2IRR00Software Design

2IRR00 · Topic 09

Concurrency, GUIs & Command

Threads, race conditions, SwingWorker, Command, undo/redo

Concurrency & threads

Concurrency runs multiple processes/threads in parallel. Problems arise because threads share memory and statements are not atomic, leading to race conditions.

Even ++x is not atomic: read x → register, increment register, write back. Interleaving threads can lose updates.

With 100 threads each doing ++x 100 times on a shared x, the result can be as low as 2 (not 10 000) due to interleaving.

Create a thread by extending Thread or implementing Runnable, then call start() (NOT run() — run() just executes inline without a new thread).

Make a singleton thread-safe via eager init or a synchronized getInstance(); you can also synchronize statements or check isAlive().

Double-click this block to add a note to Concurrency & threads.

Common mistakes

  • Calling thread.run() instead of thread.start() (no real thread is created).
  • Sharing mutable state across threads without synchronization.
Double-click this block to add a note to Common mistakes.

Exam tips

  • start() creates a thread; run() does not.
  • Race condition = result depends on thread interleaving on shared memory.
Double-click this block to add a note to Exam tips.

Concurrency & threads practice

1 questions

Question 1/1 · 0 reviews recorded
Self-review
Why call start() and not run() on a Thread?
Double-click this block to add a note to Concurrency & threads practice.

Swing & SwingWorker

Swing is Java's desktop GUI library. SwingWorker<T,V> runs a long task on a background thread so the GUI stays responsive, with T = result type and V = intermediate type.

Swing thread types: initial thread (starts in main), event dispatch thread (EDT, handles events/UI), worker/background threads (long tasks). Most non-thread-safe UI work must happen on the EDT.

Quick actions (e.g. exit) run on the EDT; long actions go to a SwingWorker so the GUI does not hang.

SwingWorker methods: doInBackground() runs the actual work off the EDT and returns T; process(List<V> chunks) handles intermediate results published via publish(); done() runs after completion, with the result available via get(). Call worker.execute() to start — never call these methods directly.

Double-click this block to add a note to Swing & SwingWorker.
SwingWorker skeleton (exam Q25–27)
SwingWorker worker = new SwingWorker<Boolean, Integer>() {
  protected Boolean doInBackground() { /* long task */ return true; }  // off EDT
  protected void process(List<Integer> chunks) { /* intermediate */ }
  protected void done() { try { Boolean r = get(); } catch (...) {} }  // after
};
worker.execute();
Double-click this block to add a note to swing-swingworker-example.

Common mistakes

  • Calling doInBackground()/process()/done() directly instead of execute().
Double-click this block to add a note to Common mistakes.

Exam tips

  • General idea of SwingWorker (MCQ): run a task in a background thread ✔, keep the GUI responsive for longer tasks ✔. NOT for short commands or initialising GUI elements.
  • <T,V>: T = doInBackground/get return type; V = intermediate (process) type.
  • doInBackground = the work; process = intermediate data; done = after-completion (get() retrieves result).
Double-click this block to add a note to Exam tips.
Double-click this block to add a note to Memory aid.

Swing & SwingWorker practice

1 questions

Question 1/1 · 0 reviews recorded
Self-review
What do doInBackground, process and done each do?
Double-click this block to add a note to Swing & SwingWorker practice.

Command pattern & undo/redo

Command encapsulates a request with all the information needed to execute it later, decoupling the call data from the moment of calling.

A command defines what method to call, on which object (receiver), with which arguments, and what to do with the result. Roles: Client, Command (abstract, execute()), ConcreteCommand, Invoker, Receiver.

Used for undo/redo, queues, logging, GUI buttons/menu items.

Undo/redo method 1: store full state before each command on a stack; undo pops and restores; redo uses a second stack. Method 2: each command knows execute() AND revert(); store command objects on a stack — do/undo/redo by executing/reverting.

Compound commands (sequences, can nest) use the Composite pattern; execute in order, revert in reverse order.

Double-click this block to add a note to Command pattern & undo/redo.
Command with revert for undo
interface Command { void execute(); void revert();
  default boolean canBeReverted() { return true; } }
class LightOnCommand implements Command {
  Light light;
  public void execute() { light.switchOn(); }
  public void revert()  { light.switchOff(); }
}
// Controller keeps undoStack & redoStack of Command
Double-click this block to add a note to command-example.

Common mistakes

  • Assuming every command is undoable — guard with canBeReverted().
Double-click this block to add a note to Common mistakes.

Exam tips

  • Command ideas (MCQ): encapsulating info needed to execute a request at any time ✔; decoupling data and moment of calling ✔. NOT 'requesting the user to do something' / 'sending to different systems'.
Double-click this block to add a note to Exam tips.
Double-click this block to add a note to Memory aid.

Command pattern & undo/redo practice

1 questions

Question 1/1 · 0 reviews recorded
Self-review
Which ideas relate to the command pattern?
Double-click this block to add a note to Command pattern & undo/redo practice.