Why is it the caller's responsibility to ensure thread safety in GUI programming?

Question

I have seen, in many places, that it is canonical wisdom¹ that it is the responsibility of the caller to ensure you are on the UI thread when updating UI components (specifically, in Java Swing, that you are on the Event Dispatch Thread).

Why is this so? The Event Dispatch Thread is a concern of the view in MVC / MVP / MVVM; to handle it anywhere but the view creates a tight coupling between the view's implementation, and the threading model of that view's implementation.

Specifically, let's say I have an MVC architected application that uses Swing. If the caller is responsible for updating components on the Event Dispatch Thread, then if I try to swap out my Swing View implementation for a JavaFX implementation, I must change all the Presenter / Controller code to use the JavaFX Application thread instead.

So, I suppose I have two questions:

1. Why is it the caller's responsibility to ensure UI component thread safety? Where is the flaw in my reasoning above?
2. How can I design my application to have loose coupling of these thread safety concerns, yet still be appropriately thread-safe?

---

Let me add some MCVE Java code to illustratrate what I mean by "caller responsible" (there are some other good practices here that I'm not doing but I'm trying on purpose to be as minimal as possible):

Caller being responsible:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        view.setData(data);
      }
    });
  }
}

public class View {
  void setData(Data data) {
    component.setText(data.getMessage());
  }
}

View being responsible:

public class Presenter {
  private final View;

  void updateViewWithNewData(final Data data) {
    view.setData(data);
  }
}

public class View {
  void setData(Data data) {
    EventQueue.invokeLater(new Runnable() {
      public void run() {
        component.setText(data.getMessage());
      }
    });
  }
}

---

_{1: The author of that post has the highest tag score in Swing on Stack Overflow. He says this all over the place and I have also seen it being the caller's responsibility in other places, too.}

Answer 1

Because making the GUI lib thread safe is a massive headache and a bottleneck.

Control flow in GUIs often goes in 2 directions from the event queue to root window to the gui widgets and from the application code to the widget propagated up to the root window.

Devising a locking strategy that isn't lock the root window (will cause a lot of contention) is difficult. Locking bottom up while another thread is locking top down is a great way to achieve instant deadlock.

And checking if the current thread is the gui thread each time is costly and can cause confusion about what is actually happening with the gui, especially when you are doing a read update write sequence. That needs to have a lock on the data to avoid races.

Answer 2

Toward the end of his failed dream essay, Graham Hamilton (a major Java architect) mentions if developers "are to preserve the equivalence with an event queue model, they will need to follow various non-obvious rules," and having a visible and explicit event queue model "seems to help people to more reliably follow the model and thus construct GUI programs that work reliably."

In other words, if you try to put a multithreaded facade on top of an event queue model, the abstraction will occasionally leak in non-obvious ways that are extremely difficult to debug. It seems like it will work on paper, but ends up falling apart in production.

Adding small wrappers around single components probably isn't going to be problematic, like to update a progress bar from a worker thread. If you try to do something more complex that requires multiple locks, it starts getting really difficult to reason about how the multithreaded layer and the event queue layer interact.

Note that these kinds of issues are universal to all GUI toolkits. Presuming an event dispatch model in your presenter/controller isn't tightly coupling you to only one specific GUI toolkit's concurrency model, it's coupling you to all of them. The event queueing interface shouldn't be that hard to abstract.

Answer 3

Threadedness (in a shared memory model) is a property that tends to defy abstraction efforts. A simple example is a Set-type: while Contains(..) and Add(...) and Update(...) is a perfectly valid API in a single threaded scenario, the multi-threaded scenario needs a AddOrUpdate.

The same thing applies to the UI - if you want to display a list of items with a count of the items on top of the list, you need to update both on every change.

1. The toolkit can't solve that problem as locking doesn't make sure the order of operations stays correct.
2. The view can solve the problem, but only if you allow the business rule that the number on top of the list has to match the number of items in the list and only update the list through the view. Not exactly what MVC is supposed to be.
3. The presenter can solve it, but needs to aware that the view has special needs with regards to threading.
4. Databinding to a multi-threading capable model is another option. But that complicates the model with things that should be UI-concerns.

None of those looks really tempting. Making the presenter responsible for handling threading is recommended not because it is good, but because it works and the alternatives are worse.

Answer 4

I read a really good blog some time ago which discuss this issue (mentioned by Karl Bielefeldt), what it basically says is that it is very dangerous to try and make the UI kit thread safe, as it introduces possible deadlocks and depending on how it's implemented, race conditions into the framework.

There is also a performance consideration. Not so much now, but when Swing was first released it was heavily criticised for it's performance (been bad), but that wasn't really Swing's fault, it was people's lack of knowledge with how to use it.

SWT enforces the concept of thread safety by throwing exceptions if your violate it, not pretty, but at least you're made aware of it.

If you look into the painting process, for example, the order in which elements are painted is very important. You don't want the painting of one component to have a side effect on any other part of the screen. Imagine if you could update a label's text property, but it was painted by two different threads, you could end up with a corrupted output. So all painting is done within a single thread, normally based on the order of requirements/requests (but sometimes condensed to reduce the number of actual physical paint cycles)

You mention changing from Swing to JavaFX, but you'd have this problem with just about any UI framework (not just thick clients, but web as well), Swing just seems to be the one which highlights the problem.

You could design a intermediate layer (a controller of a controller?) whose job it is to ensure that calls to the UI are synchronised correctly. It's impossible to know exactly how you might design your non-UI parts of your API from the perspective of the UI API and most developers would complain that any thread protection implemented into the UI API was to restrictive or didn't meet their needs. Better to allow you to decide how you want to solve this issue, based on your needs

One of the biggest issues you need to consider is the ability to justify a given order of events, based on known inputs. For example, if the user resizes the window, the Event Queue model guarantees that a given order of events will occur, this might seem simple, but if the queue allowed events to triggered by other threads, then you can no longer guarantee the order in which the events might occur (a race condition) and all of sudden you have to start worrying about different states and not doing one thing until something else happens and you start having to share state flags around and you end up with spaghetti.

Okay, you might solve this by having some kind of queue which ordered the events based on the time they were issued, but isn't that what we already have? Besides, you could still no guarantee that thread B would generate it's events AFTER thread A

The main reason people get upset about having to think about their code, is because they are made to think about their code/design. "Why can't it be simpler?" It can't be simpler, because it's not a simple problem.

I remember when the PS3 was been released and Sony was up-talking the Cell processor and it's ability to perform separate lines of logics, decode audio, video, load and resolve model data. One game developer asked, "That's all awesome, but how do you synchronize the streams?"

The problem the developer was talking about was, at some point, all those separate streams would need to be synchronized down to single pipe for output. The poor presenter simply shrugged as it wasn't a issue they were familiar with. Obviously, they've had solutions to solve this problem now, but it has funny at the time.

Modern computers are taking a lot of input from a lot of different places simultaneously, all that input needs to be processed and delivered to the user in away which doesn't interfere with the presentation of other information, so it's a complex problem, with out a single simple solution.

Now, having the ability to switch frameworks, that's not an easy thing to design for, BUT, take MVC for a moment, MVC can be multi layered, that is, you could have a MVC which deals directly with managing the UI framework, you could then wrap that, again, in a higher layer MVC which deals with interactions with other (potentially multi threaded) frameworks, it would be the responsibility of this layer to determine how the lower MVC layer is notified/updated.

You would then use coding to interface design patterns and factory or builder patterns to construct these different layers. This means, that you multithreaded frameworks become decoupled from the UI layer through the use of a middle layer, as an idea.