Pourquoi les éléments UI doivent-ils toujours être créés / mis à jour à partir du fil de l'interface utilisateur?
in (presque?) Tous les langages de programmation Les éléments d'interface utilisateur peuvent être accessibles en toute sécurité / modifiés uniquement à partir du fil de l'interface utilisateur. Je comprends que c'est un problème d'accès et de synchronisation standard, mais est-ce vraiment nécessaire? Ce comportement est-il imposé par les langages de programmation ou par le système d'exploitation? Y a-t-il des langages de programmation où cette situation est différente?
3 Réponses :
Il est imposé par le cadre graphique - qui est souvent (mais pas toujours) fourni par le système d'exploitation.
Fondamentalement, tout faire "correctement threadsafe" est inefficace. Bien que ce soit certainement une douleur nécessaire à la maréchal rappelle au fil de l'UI, elle permet au fil de l'interface utilisateur de traiter des événements extrêmement rapidement sans avoir à s'inquiéter de la verrouillage, etc.
Ne serait-il pas plus facile pour le cadre de faire le chèque et de marshall l'appel lui-même au lieu de prendre le risque de faire appel à quelqu'un de manière dangereuse en premier lieu? Le .NET Framework aurait pu le faire pour nous au moins ...
Je dirais non. Si vous appelez un appel à une propriété de texte de Textbox, c'est maintenant un ensemble assez rapide. Si vous poussez la manipulation dans le cadre, Chaque appel sera lié par cette pénalité, même si la majorité des mises à jour provenaient du fil de l'interface utilisateur elle-même.
@zaladane: Je pense que cela pourrait ne pas être si facile à déterminer (automatiquement) lorsque le code est requis pour exécuter sur le fil de l'interface utilisateur. Je ferais favoriser une construction dans la langue (peut-être un peu comme le mot-clé dangereux) pour exécuter une pièce spécifique de code sur le fil de l'interface utilisateur. Ce serait un peu plus facile à lire que le code Dispatcher.
@ZYPHRAX: Je pensais déterminer que c'était la partie facile. Vous appelez à la propriété invoquée du formulaire et si c'est vrai, vous appelez Begweinvoke ou invoquez une méthode qui fait ce que vous devez faire. Sinon, vous appelez cette méthode directement.
Bien sûr, cela suppose que vous utilisez le cadre .NET. Néanmoins, si le framework .NET peut le rendre aussi facile que d'appeler une propriété, ce n'est pas si difficile?
@Jasonh: Le problème est que la vérification de l'invocation ou non est nécessaire peut être chère - vous ne voulez pas que cela se produise pour chaque mouvement de souris, etc. Si vous savez déjà que vous êtes dans le bon fil.
Ce serait très coûteux (lent) de faire toute la sécurité de l'UI. Mieux vaut mettre le fardeau du programmeur à synchroniser dans l'occasion (relativement rare) Un thread doit mettre à jour l'interface utilisateur.
C'est parce que le cadre UI a été conçu de cette façon. Il est théoriquement possible de concevoir un cadre d'interface utilisateur qui est vraiment multi-fileté, mais il est difficile d'éviter les blocages.
Graham Hamilton a écrit un bel article à ce sujet à ce sujet En référence à Swing, le principal cadre UI Java.