Средства управления.NET: Почему все вызовы не ориентированы на многопотоковое исполнение?
После взрыва с волнением по приобретению знаний о том, как выполнить ориентированные на многопотоковое исполнение вызовы к Средствам управления Windows Form, это получило меня взгляды...
Почему все вызовы не к ориентированным на многопотоковое исполнение Средствам управления Windows Form? Кто-либо может объяснить почему? Я думал бы, что это уменьшит много беспорядка для пользователей тех средств управления.
4 ответа
Проблема здесь не в безопасности потоков. Все методы являются «потокобезопасными» в том смысле, что они не повреждают состояние приложения при одновременном вызове в нескольких потоках - просто потокобезопасность включает в себя выдачу исключения неправильного потока (не могу вспомнить, что это вызвано).
У них есть сходство потоков - они могут быть вызваны только в одном потоке - иногда называемом потоком пользовательского интерфейса, хотя это вводит в заблуждение, поскольку подразумевает, что существует только один поток. Это происходит главным образом потому, что вызовы ОС, от которых они зависят, имеют одинаковые правила сходства потоков.
Поверьте, это хорошая вещь. Когда вы думаете о главной роли «потока пользовательского интерфейса», все начинает проясняться. Задача потоков пользовательского интерфейса состоит в том, чтобы принимать входные данные от рук пользователя с помощью клавиатуры или мыши, воздействовать на них и в ответ вырабатывать выходные данные в виде пикселей. Есть только один пользователь, и у этого пользователя только одна пара глаз. Пользователь ожидает увидеть на экране все, что он делает, и, что наиболее важно, он ожидает, что это произойдет в том порядке, в котором он это сделал. Многопоточный интерфейс сделает это очень трудным - почти невозможным.
Проблема в том, что когда вы смешиваете фоновые «рабочие» потоки с потоком пользовательского интерфейса, вам необходимо выполнить определенное количество маршалинга, чтобы взаимодействовать с пользовательским интерфейсом, потому что для этого вы должны находиться в потоке пользовательского интерфейса. Опять же, как я уже сказал, это хорошо. Кто-то должен выполнить эту сортировку, иначе пользователь увидит, что что-то происходит в неправильном порядке, и это плохо. По общему признанию, система могла бы сделать это за вас, и в некоторых вызовах WIN32 она делает, но с этим есть проблемы.Во-первых, система не может знать, с какой степенью детализации вам нужно выполнить маршаллинг, поэтому вы можете оказаться неэффективным. Ваши операции могут быть лучше организованы на более высоком уровне, чем может понять система. Во-вторых, маршаллинг стоит дорого и наказывает разработчиков, которые поступают правильно и правильно переносят все в поток пользовательского интерфейса. Таким образом, система делает минимальное возможное: проверяет, находится ли он в правильном потоке, а если нет, генерирует исключение.
На самом деле проблема в том, что windows forms использует собственные ресурсы, такие как GDI объекты, для рендеринга форм/контролов.
Эти ресурсы GDI могут быть использованы только из потока, который их создал, скорее всего, из главного потока.
Таким образом, любой вызов формы/контроллера, который должен обновить gui и, следовательно, перерисовать, используя ресурсы GDI, должен быть сделан в главном потоке.
Поэтому входящие вызовы из других потоков, которые хотят это сделать, должны быть переданы главному потоку. Я не совсем уверен, как это работает за кулисами, но я предполагаю, что это достигается путем посылки сообщений в wnd-процесс формы/компонента. Как только основной поток обработает это сообщение в wndproc, он сможет вызвать фактический код. И это будет очень дорого с точки зрения производительности.
В развитие ответа Дарина:
В большинстве случаев элементы управления Windows Form Controls не нуждаются в потокобезопасности, поскольку доступ к ним обычно осуществляется из потока UI.
Иногда это необходимо (как, например, в вашем коде).
Таким образом, добавление кода проверки потоков добавит неприемлемые накладные расходы на производительность в 95%+ случаев, когда он не нужен.
Поскольку это снизит производительность, и написание безблокирующего поточно-безопасного кода по-прежнему является областью активных исследований.