Multithreaded toolkits: A failed dream? (2004)
weblogs.java.net
Multithreaded toolkits: A failed dream? (2004)
1–10 of 64 posts
Re: Multithreaded toolkits: A failed dream? (2004)
#2Photon, the old GUI for QNX, supports some degree of multithreading. You can update the values of various display elements such as meters, progress bars, and text displays from other threads. That GUI is often used for control panels, with real-time data coming in that needs to be current on the display, which is why they made that work.
It's going to be interesting to see what happens when someone implements a new GUI in Rust. The classic problem with GUIs has been that ownership management for both allocation and locking was a big problem. Rust's borrow checker can help a lot with the bookkeeping needed to get that right.
Re: Multithreaded toolkits: A failed dream? (2004)
#3BeOS did this fairly well, although I would say the biggest problem is when you activate the UI and the underlying app has become unresponsive... When your app crashes, you want your UI to reflect the crashed state of the app and similarly become unresponsive.
Re: Multithreaded toolkits: A failed dream? (2004)
#4Photon, the old GUI for QNX, supports some degree of multithreading. You can update the values of various display elements such as meters, progress bars, and text displays from other threads. That GUI is often used for control panels, with real-time data coming in that needs to be current on the display, which is why they made that work. It's going to be interesting to see what happens when someone implements a new G…
Rust prevents races but not deadlocks, which is one of the bigger problems in multithreaded GUI code.
Re: Multithreaded toolkits: A failed dream? (2004)
#5Photon, the old GUI for QNX, supports some degree of multithreading. You can update the values of various display elements such as meters, progress bars, and text displays from other threads. That GUI is often used for control panels, with real-time data coming in that needs to be current on the display, which is why they made that work. It's going to be interesting to see what happens when someone implements a new G…
Rust prevents races but not deadlocks, which is one of the bigger problems in multithreaded GUI code.
Locks turn out to be unnecessary for multithreaded code. A ringbuffer of messages is only slightly more complex, yet the gains are massive. Both in performance and simplicity.
It's possible to manage a ringbuffer without any locks. The trick is to have a counter for the producer thread, and a counter for each consumer thread. Whenever the producer wants to know "Is it safe to add a message?" it takes the minimum of all consumer counters, modulo the size of the ringbuffer. The result is the smallest index that the producer must not write beyond.
In other words, you always know when you're producing messages too quickly and need to wait on the consumers. And the consumers know when there's a message waiting -- they just look at the producer's counter. Blazingly fast, and no locks. Cool trick!
Re: Multithreaded toolkits: A failed dream? (2004)
#6Earlier quoted context omitted.
Rust prevents races but not deadlocks, which is one of the bigger problems in multithreaded GUI code.
Locks turn out to be unnecessary for multithreaded code. A ringbuffer of messages is only slightly more complex, yet the gains are massive. Both in performance and simplicity. It's possible to manage a ringbuffer without any locks. The trick is to have a counter for the producer thread, and a counter for each consumer thread. Whenever the producer wants to know "Is it safe to add a message?" it takes the minimum of a…
One can probably argue it's not even more complex at all.
Locks just look simple because it's "just chuck a mutex around it", in reality though it's all a mirage. Locks are comfortable, not simple - is how I like to put it at least.
Re: Multithreaded toolkits: A failed dream? (2004)
#7A big reason why multithreaded UI doesn't work is that the platform code (win32, cocoa) generally has poor support for interacting with OS objects from multiple threads. For instance, NSView instances can only be operated on from the main thread (https://developer.apple.com/library/mac/documentation/Cocoa/...).
Handling OpenGL context access from multiple threads is terrible, too. I'm quite excited about the additional threading niceties that we're getting in Vulkan, which should allow separate threads to re-render parts of the UI and then send the command buffers back to the main thread.
Re: Multithreaded toolkits: A failed dream? (2004)
#8What about functional reactive programming? And what about flux pattern? Didn't these resolve this "failed dream" of multi-threaded GUI update? (I am asking real, not rhetorical, questions.)
Re: Multithreaded toolkits: A failed dream? (2004)
#9What about functional reactive programming? And what about flux pattern? Didn't these resolve this "failed dream" of multi-threaded GUI update? (I am asking real, not rhetorical, questions.)
Don't see how this has anything to do with anything.
For example, the "flux" pattern is similar to model/view which can be done by a single thread (ie, Qt). In this scheme the main thread services events sequentially, calling the necessarily object's methods on the same thread.
The discussion is about the 'dream' of pushing a button from a worker thread.
Re: Multithreaded toolkits: A failed dream? (2004)
#10Well, its also a poorly motivated dream unless you have a sexual fetish for the Java style of abstraction where everything is completely independent. Who the heck wants multi-threaded GUIs?
User interaction proceeds sequentially, so most objects don't require locks. The rare exceptions in my software is rendering or IO on a separate thread, and these don't nicely fit abstraction models, as mentioned in other posts they involve C-style state machines like OGL.
A multi-threaded GUI seems like a great way to kill performance, with little advantage.