Why GUIs are Single-threaded

[Saham]

I found something like this some time back:
http://codeidol.com/java/java-concurrency/GUI-Applications/Why-are-GUIs-Single-threaded/

It has to do with the difficulty in locking the GUI components in the right order every time so you don't get thread deadlock, and it is a problem experienced from the start of GUI development at Xerox Parc and all the rest since.

These problems persist despite very bright minds grappling with them.

And so the result is the various GUIs just make it easier to schedule GUI operations on their version of the Event Dispatch Thread.

 

[dacha]

GUIs are single threaded because their world is single threaded. GPU memory is single-ported: reading or writing framebuffer contents from multiple threads is not any faster than just using 1.

 

[Saham]

GUIs are single threaded because their world is single threaded. GPU memory is single-ported: reading or writing framebuffer contents from multiple threads is not any faster than just using 1.

Sorry but I'd like to disagree with you on this point. I've seen this argument in many places, but if all multi-tasking operating systems can organize multi-threaded access to hardware such as the USB port and harddisk, surely they could co-ordinate such access to the GPU?

From the first link in this thread:

(AWT originally tried to support a greater degree of multithreaded access, and the decision to make Swing single-threaded was based largely on experience with AWT.)

 

[Saham]

Finally, I've found the article written by one of the AWT developers which explains the lot:
https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-toolkits-failed-dream
And the link to that with a short summary:
http://stackoverflow.com/a/5544714

 

[[)roi(]]

Finally, I've found the article written by one of the AWT developers which explains the lot:
https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-toolkits-failed-dream
And the link to that with a short summary:
http://stackoverflow.com/a/5544714

The notion about not being able to multi thread UI and/or the run loop is certainly not absolute; it however does require a vastly different approach to the problem; much as concurrency in the whole needs the same.

Here's a link to a talk given by John Carmack at Quakecon 2013 on this; with a link to the part where he addresses opportunities to run the game engine in parallel using a Functional Programming approach.

In short we're not there yet; but all indicators show it's a matter of "when" rather than "if".

 

[cguy]

GUIs are single threaded because their world is single threaded. GPU memory is single-ported: reading or writing framebuffer contents from multiple threads is not any faster than just using 1.

Sorry but I'd like to disagree with you on this point. I've seen this argument in many places, but if all multi-tasking operating systems can organize multi-threaded access to hardware such as the USB port and harddisk, surely they could co-ordinate such access to the GPU?

From the first link in this thread:

The top post doesn't even make any sense. Applications don't write to GPU memory (except for a few very special cases), they build up command buffers, which the OS schedules into a list. The GPU executes these as given, and can support a limited amount of preemption (e.g., to prevent GPU compute tasks from monopolizing the hardware).

Assuming a non-3D API based GUI, the frame buffer being written to is normal DRAM, and it is much faster to write this with multiple threads, since the write request queue for a given CPU is generally too small to support enough requests to saturate memory bandwidth.

 

[[)roi(]]

To add to my last post:
It's important to understand that the reason why GUIs today are single threaded is directly related to our inability to deal with complexity and conflicts. The current approach to this problem involves trying to multithread many parts of a runloop; a complex juggling act with far too many balls (activities) to juggle synchronously within the constraints of a single frame.

As with every problem; there is more than one way to skin a cat; Functional Programming is exactly that: a completely different approach to the same problem; one that specifically avoids conflicts, isolating state to make concurrency easier.

Here's an example where a different approach to the same problem yielded substantially better results with a Functional approach to the same problem:
Darpa conducted a study in the 90s called "An Experiment in Software Prototyping Productivity"; the results of this study were very surprising and ultimately has led to growth of the Functional Programming paradigm. Basically the study pitted a group of languages against each other; the Darpa problem presented naturally involved a military style problem.

The outcome stunned everyone:


The Haskell solution comprised only 85 lines of code, whereas C++ was 1105. What was even more surprising is that with type inference we could have eliminated another 29 lines of Haskell code. i.e. 56 lines versus 1105 of C++.

The results were so unbelievable that Darpa hired another college graduate who had never used Haskell to learn it within 8 days. His submission was 156 lines of Haskell code. Which ultimately explains why this paradigm has received more focus in the last 2 decades.

So does this mean that GUIs can be multithreaded;

• Yes, it's very likely given enough time; but it's a research topic (as John Carmack mentioned in the video I linked)

Does this mean it will be significantly faster than current approaches:

• Maybe, but the biggest gains will more likely be design robustness, ease of maintenance and extensibility.

 

[^^vampire^^]

When you play around with parallel programming then you will see that sometimes your parallel processes are slower than your inline processes. You will also see that as soon as you start introducing multiple parallels it can become harder and harder to manage, and more so to manage correctly - never mind the possible thread locks waiting for on other processes to complete.

Like others have said, when it becomes easier to manage the parallels then maybe the GUI will be split/multi threaded. Managing whether it is better, performance wise, to multi thread a GUI is hard enough when you know exactly what is happening - I would hate to have to build an implementation that handles this from a level of abstraction.

 

[Saham]

From Multithreaded toolkits: A failed dream? I linked to above:

Some problems have nasty hidden details which prevent a workable solution from being found.

If the bright minds at Microsoft, IBM, the old Sun Microsystems, and even the original GUI designers at Xerox Parc, all gave up on finding a workable solution for a multi-threaded GUI, despite all the advancements in computing in the last decades, then it is better to accept that this detail won't change any time soon.

I'm quite sure that research into this will continue, though, because a multi-threaded GUI would mean that applications would need much less threading, reducing their complexity. A very grand prize indeed.

 

[Batista]

Had to do this the other day, do a background copy operation because if I did it in the main thread then the GUI goes into a not responding state and therefore cant show the process.

 

[[)roi(]]

From Multithreaded toolkits: A failed dream? I linked to above:

Some problems have nasty hidden details which prevent a workable solution from being found.

If the bright minds at Microsoft, IBM, the old Sun Microsystems, and even the original GUI designers at Xerox Parc, all gave up on finding a workable solution for a multi-threaded GUI, despite all the advancements in computing in the last decades, then it is better to accept that this detail won't change any time soon.

I'm quite sure that research into this will continue, though, because a multi-threaded GUI would mean that applications would need much less threading, reducing their complexity. A very grand prize indeed.

All that we can say for sure is that the current approach to the problem requires a level of complexity we can't fathom; and this is btw not just limited to GUIs. Personally; humans don't cope well with conflict anyway, so it shouldn't be a surprise we can't solve problems involving conflict. As for history; that approach was based on primarily an iterative and mutable approach.

Functional Programming, Category Theory and the like tackle problems completely different to the current iterative / mutable approach; the key difference being immutability, which simply means each thread would be granted autonomy, no overlap, no conflict, .... As for why it's not yet solved; it's a matter of priority and funding; this area of programming has many unexplored aspects, so it's no surprise we're not actively working on something that already has a workable solution. The focus is more on concurrency as a whole, finding solutions to more effectively implement parallel processing in a way that humans programmers can comprehend it.

 

[cguy]

From Multithreaded toolkits: A failed dream? I linked to above:

Some problems have nasty hidden details which prevent a workable solution from being found.

If the bright minds at Microsoft, IBM, the old Sun Microsystems, and even the original GUI designers at Xerox Parc, all gave up on finding a workable solution for a multi-threaded GUI, despite all the advancements in computing in the last decades, then it is better to accept that this detail won't change any time soon.

I'm quite sure that research into this will continue, though, because a multi-threaded GUI would mean that applications would need much less threading, reducing their complexity. A very grand prize indeed.

I expect that the reason this hasn't been solved is that it's not really a problem. Why would anyone even want to multithreaded a GUI today? To keep it interactive it just needs to deliver work that is non-trivial to one or more worker threads, while it only processes trivial tasks and its own event loop.

 

[[)roi(]]

I expect that the reason this hasn't been solved is that it's not really a problem. Why would anyone even want to multithreaded a GUI today? To keep it interactive it just needs to deliver work that is non-trivial to one or more worker threads, while it only processes trivial tasks and its own event loop.

I agree for the most part; it's a solution looking for a problem that isn't..

... however when you listen to talks from John Carmack, Erik Meijer, ... on the subject it easy to appreciate the potential for simplification / benefit; plus personally hitting the inevitable I can functionally approach most everything in the codebase except the UI (the key limitation being the frameworks); it's not hard to appreciate why it would be nice to have... but nice to have certainly isn't a priority.

 

[cguy]

I agree for the most part; it's a solution looking for a problem that isn't..

... however when you listen to talks from John Carmack, Erik Meijer, ... on the subject it easy to appreciate the potential for simplification / benefit; plus personally hitting the inevitable I can functionally approach most everything in the codebase except the UI (the key limitation being the frameworks); it's not hard to appreciate why it would be nice to have... but nice to have certainly isn't a priority.

I can see that as a functional programmer, having that model moved to the GUI framework may be interesting. I think that is separate from the point at hand though: multithreading. Even though functional GUI code could be trivially multithreaded, there is still no point in doing so. It's just going to create system overhead.

 

[[)roi(]]

I can see that as a functional programmer, having that model moved to the GUI framework may be interesting. I think that is separate from the point at hand though: multithreading. Even though functional GUI code could be theoretically trivially multithreaded, there is still no point in doing so. It's just going to create system overhead.

Added "theoretically"...

Functionally we already have a number of ways to address the shortfalls (Promises / Futures / Reactive / ...) so in general that's fairly well covered atm. As for the whole, its highly debatable, but there was a time when 640K was considered enough, more recently we have this type of counter argument against this pursuit. It really depends on your point of view wrt central computing vs. continually scaling up local resource. Today I agree it's a problem looking for a reason.