Как будет выглядеть многопоточный пользовательский интерфейс API и какие преимущества он даст?

Question

Или, что эквивалентно, как бы вы разработали такой API. Предполагаемое / примерное использование также будет иллюстративным.

Мое любопытство исходит непосредственно из комментариев (и последующего редактирования с моей стороны) этого ответа . Подобные вопросы / дискуссии в прошлом давали немного вдохновения для того, чтобы на самом деле их задавать.

Резюме:
Я не чувствую, что многопоточный интерфейс API возможен осмысленным образом и не особенно желателен. Эта точка зрения представляется несколько спорным и быть (относительно) скромный человек, которого я хотел бы видеть ошибки моего пути, если они на самом деле являются ошибочными.

_{* Многопоточность определена довольно свободно в этом контексте, однако ** это имеет смысл для вас.}

---

Поскольку это довольно свободная форма, я буду принимать любой ответ, который, на мой взгляд, имеет наиболее последовательный и хорошо поддерживаемый ответ; независимо от того, согласен ли я с этим.

Ответ принят

---

** Хорошо, возможно, необходимы дополнительные разъяснения.

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

Я не считаю это многопоточным пользовательским интерфейсом.

Вся работа с пользовательским интерфейсом выполняется на одном потоке. Я бы сказал, что на базовом уровне многопоточный API пользовательского интерфейса должен был бы покончить с (каким-то образом) владением потоками объектов UI или отправкой событий в один поток.

Помните, это касается самого API пользовательского интерфейса; не приложения, которые его используют.

Answer 1

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

• (Если используется язык не-GC, такой как C ++) Время жизни объекта отслеживается упаковщиками указателей с подсчетом ссылок, такими как std :: tr1 :: shared_ptr. Это гарантирует, что вы не участвуете в потоке, пытаясь удалить объект.
• Все методы являются реентерабельными, поточно-ориентированными и гарантированно не блокируют обратные вызовы событий (следовательно, обратные вызовы событий не должны вызываться при удержании блокировок)
• Необходимо указать общий заказ на замки; например, реализация метода в элементе управления может вызывать методы только в дочерних элементах управления, кроме как путем планирования асинхронного обратного вызова для запуска позже или в другом потоке.

С этими двумя изменениями вы можете применить это практически к любой среде GUI, которая вам нравится. Нет необходимости в массовых изменениях; однако дополнительные накладные расходы на блокировку замедляют его, а ограничения на порядок блокировки сделают разработку пользовательских элементов управления несколько более сложной.

Поскольку это обычно доставляет гораздо больше хлопот, чем стоит, большинство фреймворков с графическим интерфейсом занимают промежуточное положение; Объектами пользовательского интерфейса, как правило, можно манипулировать только из потока пользовательского интерфейса (некоторые системы, такие как win32, допускают наличие нескольких потоков пользовательского интерфейса с отдельными объектами пользовательского интерфейса), а для связи между потоками существует поточный безопасный метод для планирования обратного вызова, который будет вызываться поток пользовательского интерфейса.

Answer 2

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

Добавление большего количества потоков, как правило, является предложением уменьшения отдачи, если вы не работаете с такими вещами, как мультитач или многопользовательский. Тем не менее, большинство мультитач-ввода, кажется, обрабатываются многопоточными на уровне драйвера, поэтому на уровне GUI это обычно не требуется. По большей части вам нужно только соотношение потоков к пользователю 1: 1 плюс некоторое постоянное число в зависимости от того, что именно вы делаете.

Например, потоки предварительного кэширования популярны. Поток может записывать любые дополнительные циклы ЦП, делая прогнозное кеширование, чтобы ускорить процесс в целом. Анимационные потоки ... Если у вас интенсивная анимация, но вы хотите сохранить отзывчивость, вы можете поместить анимацию в поток с более низким приоритетом, чем в остальной части пользовательского интерфейса. Как упоминалось выше, потоки обработчиков событий также популярны, но обычно они прозрачно предоставляются пользователям инфраструктуры.

Таким образом, определенно есть применение для потоков, но нет смысла создавать большое количество потоков для графического интерфейса. Тем не менее, если вы пишете свой собственный графический интерфейс, вам определенно придется реализовать его с использованием многопоточной модели.

Answer 3

Я не вижу никакой пользы на самом деле. Допустим, среднее приложение имеет 3 основные цели:

1. Rendering
2. Пользовательский ввод / обработчики событий
3. Хруст номера / Сеть / Диск / И т.д.

Разделение их на один поток (несколько для # 3) было бы довольно логично, и я бы назвал интерфейс № 1 и № 2.

Можно сказать, что # 1 уже многопоточный и разделен на тонны шейдерных процессоров на GPU. Я не знаю, поможет ли действительно добавление большего количества потоков в ЦП. (по крайней мере, если вы используете стандартные шейдеры, некоторые программные средства трассировки лучей IIRC и другие средства визуализации CGI используют несколько потоков - но я бы поставил такие приложения под # 3)

Методы пользовательского ввода, # 2, должны быть действительно очень короткими и вызывать материал из # 3, если требуется больше времени, что добавление большего количества потоков здесь не будет иметь никакого смысла.

Answer 4

В этом нет ничего плохого, особенно в многопоточных приложениях. Все, что вам нужно, это какая-то синхронизация между потоками и способ обновления интерфейса через границы потоков (BeginInvoke в C #, SendMessage в простом приложении Win32 и т. Д.).

Что касается использования, почти все, что вы видите, является многопоточным, от интернет-браузеров (у них есть фоновые потоки, загружающие файлы, в то время как основной поток заботится о отображении загруженных частей - опять же, используя тяжелую синхронизацию), до приложений Office ( на ум приходит функция сохранения в играх (удачи в поиске однопоточной игры с большим именем). Фактически пользовательский интерфейс WinForms C # создает новый поток для пользовательского интерфейса из коробки!

Что конкретно, на ваш взгляд, нежелательно или сложно реализовать по этому поводу?