Java Multithreading – Queue vs Threads

a single looper thread is easier to implement, understand and use compared to multiple threads, (like separate painter eventcallback threads)

because with multithreading in the GUI all access to a GUI component needs to be synchronized (only exception is immutable stuff), this would then become a major bottle neck especially in times where it was prohibitevly expensive to acquire a lock or in tightly coupled frameworks

then there's also that if the eventlisteners can be notified on any thread (whichever one happened to poll the event queue) you would require thread safety to be applied to the underlying model (this is hard to get right). Even the paint-eventcallback segregation example above would need read-write synchronization.

one thing to note is that most frameworks have the idea of a background thread to use for long calculations and IO (like SwingWorker) or atleast a way to add a event to call a certain function on the event thread (generally called invoke)

You are quite close to answering your own question. :)

In the Observable/Observer pattern (note the flip), there are three things to bear in mind:

1. Generally, the notification of the change, i.e. 'payload', is in the observable.
2. The observable exists.
3. The observers must be known to the existing observable (or else they have nothing to observe on).

By combining these points, what is implied is that the observable knows what its downstream components, i.e. the observers are. The data flow is inherently driven from the observable - observers merely 'live and die' by what they are observing on.

In the Producer/Consumer pattern, you get a very different interaction:

1. Generally, the payload exists independently of the producer responsible for producing it.
2. Producers do not know how or when consumers are active.
3. Consumers need not need to know the payload's producer.

The data flow is now completely severed between a producer and a consumer - all the producer knows is that it has an output, and all the consumer knows is that it has an input. Importantly, this means that producers and consumers can exist entirely without the presence of the other.

Another not-so-subtle difference is that multiple observers on the same observable usually gets the same payload (unless there is an unconventional implementation), whereas multiple consumers off the same producer may not. This depends if the intermediary is a queue-like or topic-like approach. The former passes a different message for each consumer, while the latter ensures (or attempts to) that all consumers processes on a per-message basis.

To fit them into your application:

• In the Observable/Observer pattern, whenever your watching thread is initializing, it must know how to inform the controller. As the observer, the controller is likely waiting for a notification from the watching thread before it lets the threads handle the change.
• In the Producer/Consumer pattern, your watching thread only needs to know the presence of the event queue, and interacts solely with that. As the consumer, the controller then polls the event queue, and once it gets a new payload, it lets the threads handle it.

Therefore, to answer your question directly: if you want to maintain some level of separation between your watching thread and your controller such that you can operate them independently, you should tend towards the Producer/Consumer pattern.