Java Reference
In-Depth Information
“bubble down” from the application to the OS—changing the background color of a compon-
ent originates in the application and is dispatched to a specific component class and eventu-
ally into the OS for rendering. Combining this tendency for activities to access the same GUI
objects in the opposite order with the requirement of making each object thread-safe yields a
recipe for inconsistent lock ordering, which leads to deadlock (see Chapter 10 ) . And this is
exactly what nearly every GUI toolkit development effort rediscovered through experience.
Another factor leading to deadlock in multithreaded GUI frameworks is the prevalence of
the model-view-control (MVC) pattern. Factoring user interactions into cooperating mod-
el, view, and controller objects greatly simplifies implementing GUI applications, but again
raises the risk of inconsistent lock ordering. The controller calls into the model, which noti-
fies the view that something has changed. But the controller can also call into the view, which
may in turn call back into the model to query the model state. The result is again inconsistent
lock ordering, with the attendant risk of deadlock.
In his weblog, [1] Sun VP Graham Hamilton nicely sums up the challenges, describing why
the multithreaded GUI toolkit is one of the recurring “failed dreams” of computer science.
I believe you can program successfully with multithreaded GUI toolkits if the toolkit is
very carefully designed; if the toolkit exposes its locking methodology in gory detail; if
you are very smart, very careful, and have a global understanding of the whole structure
of the toolkit. If you get one of these things slightly wrong, things will mostly work, but
you will get occasional hangs (due to deadlocks) or glitches (due to races). This multith-
readed approach works best for people who have been intimately involved in the design
of the toolkit.
Unfortunately, I don't think this set of characteristics scales to widespread commercial
use. What you tend to end up with is normal smart programmers building apps that don't
quite work reliably for reasons that are not at all obvious. So the authors get very dis-
gruntled and frustrated and use bad words on the poor innocent toolkit.
Single-threaded GUI frameworks achieve thread safety via thread confinement; all GUI ob-
jects, including visual components and data models, are accessed exclusively from the event
thread. Of course, this just pushes some of the thread safety burden back onto the application
developer, who must make sure these objects are properly confined.
Search WWH ::




Custom Search