Пытаюсь понять почему GUI приложения всегда однопоточные
http://codeidol.com/java/java-concurrency/GUI-Applications/Why-are-GUIs-Single-threaded/ In the old days, GUI applications were single-threaded and GUI events were processed from a "main event loop". Modern GUI frameworks use a model that is only slightly different: they create a dedicated event dispatch thread (EDT) for handling GUI events.

Single-threaded GUI frameworks are not unique to Java; Qt, NextStep, MacOS Cocoa, X Windows, and many others are also single-threaded. This is not for lack of trying; there have been many attempts to write multithreaded GUI frameworks, but because of persistent problems with race conditions and deadlock, they all eventually arrived at the single-threaded event queue model in which a dedicated thread fetches events off a queue and dispatches them to applicationdefined event handlers. (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.)

Multithreaded GUI frameworks tend to be particularly susceptible to deadlock, partially because of the unfortunate interaction between input event processing and any sensible object-oriented modeling of GUI components. Actions initiated by the user tend to "bubble up" from the OS to the applicationa mouse click is detected by the OS, is turned into a "mouse click" event by the toolkit, and is eventually delivered to an application listener as a higher level event such as a "button pressed" event. On the other hand, application-initiated actions "bubble down" from the application to the OSchanging the background color of a component originates in the application and is dispatched to a specific component class and eventually 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 model, 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 notifies 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.

[1] http://weblogs.java.net/blog/kgh/archive/2004/10

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 multithreaded 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 disgruntled and frustrated and use bad words on the poor innocent toolkit.

Single-threaded GUI frameworks achieve thread safety via thread confinement; all GUI objects, 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.

Сразу оговорюсь, что на SWING и ему подобных никогда не писал. Но понять общие принципы бы хотел раз уж сел за книгу.
1.
main event loop - не очень понимаю, что это за цикл такой. Точнее в книге не объясняется что это за чудо и нагуглить не получилось, это похоже какое-то древнее legacy. Есть предположение, что в цикле достаём из очереди(например BlockingQueue) событие и начинаем его обрабатывать, как только обработали, итерация закончилась и на следующей итерации новое сообщение достаём. Может такое быть, что в эту очередь добавляют из разных потоков?

Далее я не понял откуда появляются дедлоки если потоков много:

а).авторMultithreaded GUI frameworks tend to be particularly susceptible to deadlock, partially because of the unfortunate interaction between input event processing and any sensible object-oriented modeling of GUI components. Actions initiated by the user tend to "bubble up" from the OS to the applicationa mouse click is detected by the OS, is turned into a "mouse click" event by the toolkit, and is eventually delivered to an application listener as a higher level event such as a "button pressed" event. On the other hand, application-initiated actions "bubble down" from the application to the OSchanging the background color of a component originates in the application and is dispatched to a specific component class and eventually 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.


Тут дедлок как-то привязывается к тому, что если мы нажали мышкой на кнопкой, то ОС определяет клик мышки и баблит это до листенера приложения, который получает "button pressed" event. А в этом листенере мы что-то делаем и просим что-то изменить на GUI, что как-бы в обратную сторону баблит событие. Как-то это влияет на порядок захвата потоков. И привет дедлок.
Как-то непонятно почему это влияет на локи. и почему мы их не отпускаем когда прищли в листенер



б)

авторAnother factor leading to deadlock in multithreaded GUI frameworks is the prevalence of the model-view-control (MVC) pattern. Factoring user interactions into cooperating model, 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 notifies 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.

Тут без конкретики тоже как-то непонятно.

Я наверное как-то не так понимаю MVC, но если взять скажем spring mvc-шное приложение с JSP. Общепринятая практика в контроллере принимать запрос от view, как-то обновлять модель и когда всё успешно произошло, то что-то выплёвывать на view. Как может модель напрямую оповещать view исходя из того с чем приходилось работать - непонятно.

Andrew1411questioner,

Большинство GUI фреймворков однопоточные, потому что:
1. с ними возможно сделать качественное GUI приложение.
2. однопоточный код поддается тотальному тестированию (в отличии от многопоточного)
3. приведенная цена однопоточного кода ниже, чем у многопоточной.

Итого, они покрывают необходимые и достаточные условия, имея при этом хорошишее оношение цена/качество


Далее я не понял откуда появляются дедлоки если потоков много:
Ваш вопрос вызван тем, что вы не внимательно читали то, на что задавали вопросы

Multithreaded GUI frameworks tend to be particularly susceptible to deadlock....

Another factor leading to deadlock in multithreaded GUI frameworks is ...

не-не, я внимательно читал и вопросе уточнил, что если потоков много

Blazkowicz
questioner Есть предположение, что в цикле достаём из очереди(например BlockingQueue)

Ну, при чем тут BlockingQueue? Просто любая очередь, не важно какая.

Так как продюсеров может быть много, то видимо будет не очень хорошо, если они начнут добавлять одновременно.

Так же чувствую могут быть проблемы если одновременно добавлять и читать голову: продюсером и консумером.

BlazkowiczВ GUI куча различных объектов - это критические участки. Считай каждый контрол должен иметь лок. Событий происходит много и часто. При многопоточной обработке событий нужно как-то умудриться чтобы один поток не захватывал более одного лока.

1. Зачем потоку больше одного лока? чтобы тыкнув по одной кнопочке убиралась другая?

Допустим есть две кнопки А и B. Нажатие на A скрывает B, Нажатие на B скрывает A. Дедлок будет в такого рода случаях?

BlazkowiczА мне не понятно с какой радости контроллеру вместо модели обращаться к view


Я может в терминологии не понимаю:




Тут считается, что модель обновляет view ?

Blazkowicz,

Кстати эта модель похожа на логгирование?

P.S.
Судя по примеру из книги

BlazkowiczquestionerТак как продюсеров может быть много, то видимо будет не очень хорошо, если они начнут добавлять одновременно.

Что именно будет не хорошо? С каких это множество продюсеров для одной очереди это вдруг не хорошо?

Однопоточные коллекции не предназначены для исполнения из нескольких потоков. Разве нет? в противном случае результат непредсказуемый

BlazkowiczquestionerТак же чувствую могут быть проблемы если одновременно добавлять и читать голову: продюсером и консумером.

Продюсер не читает голову.


Я имел ввиду вырожденный случай когда голова она же хвост. То есть всего один элемент в очереди.

BlazkowiczquestionerОднопоточные коллекции не предназначены для исполнения из нескольких потоков. Разве нет? в противном случае результат непредсказуемый

Какое отношение однопоточные коллекции имеют к Event Queue? Нет проблемы синхронизировать доступ к единственной очереди. Есть проблема распараллелить все обработчики событий.

Я сейчас обсуждаю топик в контексте того, что обработчик событий один, а продючеров много.

Проблемы синхронизировать доступ нет, но кто-то это делать должен и соответственно обычная очередь не подойдёт. Такая вот логика.

BlazkowiczquestionerЯ сейчас обсуждаю топик в контексте того, что обработчик событий один, а продючеров много.
Продюсеров всегда много, потому что источники событий в GUI разные. Поэтому мне не понятно какую ещё ситуацию можно обсуждать.

Blazkowiczэто был ответ наBlazkowicz Есть проблема распараллелить все обработчики событий.
questionerобычная очередь не подойдёт
Новая классификация очередей на обычные и не обычные?

Под обычными я понимал однопоточные очереди.

Ну либо при доступе к ним использовать какую-то внешнюю синхронизацию.

Ой как криво получилось... вот так надо:
BlazkowiczquestionerЯ сейчас обсуждаю топик в контексте того, что обработчик событий один, а продючеров много.

Продюсеров всегда много, потому что источники событий в GUI разные. Поэтому мне не понятно какую ещё ситуацию можно обсуждать.



это был ответ на

BlazkowiczЕсть проблема распараллелить все обработчики событий.

Blazkowiczquestionerобычная очередь не подойдёт

Новая классификация очередей на обычные и не обычные?


Под обычными я понимал однопоточные очереди.

Ну либо при доступе к ним использовать какую-то внешнюю синхронизацию.