Pourquoi seul le thread d'interface utilisateur est-il autorisé à modifier l'interface utilisateur?

Question

Je sais que si je modifie un contrôle d'un thread différent, je devrais faire attention car WinForms et WPF ne permettent pas de modifier l'état du contrôle d'autres threads.

Pourquoi cette restriction est-elle en place?

Si je peux écrire du code thread-safe, je devrais pouvoir modifier l'état de contrôle en toute sécurité. Alors pourquoi cette restriction est-elle présente?

Answer 1

Plusieurs frameworks GUI ont cette limitation. Selon le livre Java Concurrency in Practice la raison en est d'éviter le verrouillage complexe. Le problème est que les contrôles de l'interface graphique peuvent avoir à réagir aux deux événements de l'interface utilisateur, la liaison de données et ainsi de suite, ce qui conduit à un verrouillage de plusieurs sources différentes et donc un risque d'interblocages. Pour éviter cela .NET WinForms (et autres interfaces utilisateur) restreint l'accès aux composants à un seul thread et évite ainsi le verrouillage.

Answer 2

.NET se réserve le droit d'accéder à votre contrôle dans le fil où vous l'avez créé à tout moment. Par conséquent, les accès provenant d'un autre thread ne peuvent jamais être thread safe.

Answer 3

Dans le cas de Windows, lorsqu'un contrôle est créé, les mises à jour de l'interface utilisateur sont effectuées via des messages provenant d'une pompe de message. Le programmateur n'a pas de contrôle direct du thread sur lequel la pompe fonctionne, donc l'arrivée d'un message pour un contrôle pourrait éventuellement entraîner le changement de l'état du contrôle. Si un autre thread (que le programmeur était en contrôle direct) était autorisé à changer l'état du contrôle, alors une sorte de logique de synchronisation devrait être mise en place pour empêcher la corruption de l'état du contrôle. Les contrôles dans .Net ne sont pas thread-safe; C'est, je suppose par conception. Mettre la logique de synchronisation dans tous les contrôles serait coûteux en termes de conception, de développement, de test et de support du code qui fournit cette fonctionnalité. Le programmeur peut bien sûr fournir la sécurité de thread au contrôle pour son propre code, mais pas pour le code qui est en .Net qui est en cours d'exécution en même temps que son code. Une solution à ce problème consiste à limiter ces types d'actions à un thread et à un thread uniquement, ce qui simplifie le maintien du code de contrôle dans .Net.

Answer 4

Vous pouvez créer votre propre code sans fil, mais vous n'avez aucun moyen d'injecter les primitives de synchronisation nécessaires dans le code WinForm et WPF intégré qui correspondent à ceux de votre code. Souvenez-vous qu'il y a beaucoup de messages qui circulent dans les coulisses et qui font que le thread de l'interface utilisateur accède au contrôle sans que vous en ayez vraiment conscience.

Un autre aspect intéressant d'une affinité de thread de contrôle est qu'il pourrait (bien que je soupçonne qu'ils ne le feraient jamais) utiliser le modèle Thread Local Storage. Évidemment, si vous accédiez à un contrôle sur un thread autre que celui sur lequel il était créé, il ne serait pas capable d'accéder aux données TLS correctes, peu importe avec quelle précision vous avez structuré le code pour vous protéger de tous les problèmes normaux du code multithread.

Answer 5

En fait, autant que je sache, c'était le plan depuis le début! Chaque contrôle pourrait être accessible à partir de n'importe quel fil! Et juste parce que le verrouillage des threads était nécessaire lorsqu'un autre thread nécessitait l'accès au contrôle - et parce que le verrouillage est coûteux - un nouveau modèle de thread a été conçu appelé «thread location». Dans ce modèle, les contrôles associés seraient agrégés en "contextes" en utilisant un seul thread, réduisant ainsi la quantité de verrouillage nécessaire. Assez cool, hein? Malheureusement, cette tentative était trop audacieuse pour réussir (et un peu plus complexe parce que le verrouillage était toujours nécessaire), donc le bon vieux modèle de thread Windows Forms --avec le thread UI unique et avec le thread de création pour revendiquer la propriété de le control-- est utilisé à nouveau dans wPF pour rendre nos vies ... plus faciles?

Answer 6

Windows prend en charge de nombreuses opérations qui, en particulier lorsqu'elles sont combinées, ne sont intrinsèquement pas sécurisées pour les threads. Que devrait-il se passer, par exemple, si un thread essaye d'insérer du texte dans un champ de texte en commençant par le 50ème caractère, alors qu'un autre thread essaie de supprimer les 40 premiers caractères de ce champ? Windows pourrait utiliser des verrous pour s'assurer que la seconde opération ne pourrait pas commencer avant la fin du premier, mais l'utilisation de verrous ajouterait une surcharge à chaque opération et augmenterait la possibilité d'interblocage si les actions sur une entité nécessitent manipulation d'un autre. Exiger que les actions impliquant une fenêtre particulière doivent se produire sur un thread particulier est une exigence plus stricte que ce qui serait nécessaire pour empêcher que des combinaisons d'opérations dangereuses soient effectuées simultanément, mais il est relativement facile à analyser. Utiliser des contrôles provenant de plusieurs threads et éviter les conflits via d'autres moyens serait généralement plus difficile.