Почему большинство пользовательских интерфейсов однопоточных?

Ответ 1

Что заставило дизайнеров фреймов выбрать одну модель потока над другой?

Из лошадиный рот:

AWT первоначально был показан как нормальный многопоточная библиотека Java. Но команда Java посмотрела на опыт с AWT и с тупиками и расы, с которыми столкнулись люди, мы начали понимать, что мы обещание, которое мы не могли сохранить.

Этот анализ завершился одним из обзоры дизайна для Swing в 1997 году, когда мы рассмотрели состояние игры в AWT, и общий отраслевой опыт, и мы приняли команду Swing рекомендации, чтобы Swing поддержка очень ограничена Многопоточность.

(Прочитайте всю статью, она подробно объясняет это решение и заявляет, что точно такие же проблемы и возможный переход к однопоточной модели произошли ранее в Xerox PARC - месте, где почти все, что мы рассматриваем, в CS был изобретен 30 лет назад)

Не будет многопотоковой модели пользовательского интерфейса потенциально даст вам больше производительности хотя за счет большей сложности?

Абсолютно нет, потому что рисование GUI и обработка действий пользователя (что все, что нужно для потока пользовательского интерфейса) не будет узким местом в любом нормальном 2D приложении.

Ответ 2

Не будет ли многопоточная модель пользовательского интерфейса потенциально давать вам больше производительности, хотя бы за счет большей сложности?

Не в большинстве случаев, и что добавленная сложность принесет больше вреда, чем пользы в большинстве случаев. Вы также должны понимать, что инфраструктура пользовательского интерфейса должна иметь дело с базовой моделью ОС. Конечно, он мог бы обойти модель и отвлечь ее от программиста, но в этом случае это просто не стоит.

Количество ошибок, вызванных несколькими потоками, обновляющими ad hoc ad hoc, намного перевешивало бы то, что было бы большей частью бессмысленным приростом производительности (если бы были даже выигрыши, потоковая передача с соответствующими накладными расходами из-за блокировки и синхронизации, на самом деле вы можете просто ухудшить производительность намного чаще).

В этом случае лучше использовать несколько потоков явно и только тогда, когда это необходимо. Большую часть времени в пользовательском интерфейсе вы хотите, чтобы все было на одном потоке, и вы ничего не выигрываете, если использовать несколько потоков. UI-взаимодействия почти никогда не являются узким местом.

Ответ 3

Нет, наверное, нет. По крайней мере, когда вы пытаетесь запустить потоки на CPU. На GPU уже существует много параллельной обработки в различных формах. Не так много для простой работы графического интерфейса, но для фантазии 3D (затенение, отражение и т.д.).

Ответ 4

Я думаю все о предотвращении тупиковой ситуации.

Компоненты Swing не считаются потокобезопасными, и они не обязательно должны быть из-за этого события Dispatcher Thread. Если пользовательский интерфейс был многопоточным, все приложение должно было бы полагаться на каждый компонент, ведущий себя в потокобезопасной манере, а если таковой не был, то в неясных ситуациях могут возникать взаимоблокировки.

Итак, это просто безопаснее.

Не только это, но тот же дизайн был выбран Windows Forms (&.Net), GTK, Motif и другими. Интересно, будет ли Java принуждаться к этому решению базовыми API-интерфейсами ОС, с которыми они взаимодействуют. Конечно, SWT принудительно переходит в эту ситуацию с помощью Windows Forms.

Для получения дополнительной информации "EDT" - хорошее место для запуска http://en.wikipedia.org/wiki/Event_dispatching_thread

Для .NET эквивалент SwingWorker известен как BackgroundWorker.

Ответ 5

Это связано с природой приложения пользовательского интерфейса.

Вы должны прочитать ввод (мышь или клавиатура), отправить события, позволить им обрабатывать и снова рисовать экран.

Попробуйте сделать это в многопоточном процессе.