InvokeRequired blind verwendet nicht einfach schlechte Praxis?

Question

Ich bin ein Anfänger Programmierer, also könnte ich hier völlig falsch liegen, aber dieses Problem bugs mich mehr als es sollte.

Dies ist eigentlich ein Follow-up von this Frage.

Die angenommene Antwort war, dass Sie InvokeRequired aufrufen müssen, um einige Overhead zu vermeiden, da Sie die Möglichkeit haben, bereits auf dem UIhread zu arbeiten.

In der Theorie stimme ich zu, dass es etwas Zeit sparen könnte. Nach einigen Tests habe ich herausgefunden, dass die Verwendung von Invoke ungefähr doppelt so lange dauert wie der normale Aufruf einer Operation (Tests wie das n-fache Setzen des Textes einer Beschriftung oder das Platzieren einer sehr, sehr großen Zeichenkette in einer RichTextBox).

Aber! Dann gibt es Übung.

MSDN-Dokumentation sagt:

Diese Eigenschaft verwendet werden kann, um festzustellen, ob Sie ein invoke-Methode aufrufen müssen, die nützlich sein können, wenn Sie nicht wissen, was Thread eine Kontrolle besitzt.

In den meisten Fällen Sie tun wissen, wenn Sie versuchen, eine Kontrolle von einem anderen Thread zuzugreifen. Tatsächlich ist die einzige Situation, an die ich denken kann, wenn auf das Steuerelement über eine Methode zugegriffen wird, die sowohl vom Thread X als auch vom Eigentümer-Thread aufgerufen werden kann. Und das ist für mich eine sehr unwahrscheinliche Situation.

Und selbst wenn Sie wirklich nicht wissen, welcher Thread versucht, das Steuerelement zu manipulieren, gibt es die Tatsache, dass der UI-Thread nicht so häufig aktualisiert werden muss. Alles zwischen 25-30 fps sollte für Ihre GUI in Ordnung sein. Und die meisten Änderungen, die in den UI-Steuerelementen vorgenommen werden, benötigen weit weniger als Millisekunden. Wenn ich also richtig verstehe, ist das einzige Szenario, in dem Sie prüfen müssen, ob ein Aufruf erforderlich ist, wenn Sie nicht wissen, welcher Thread auf das Steuerelement zugreift und wann das GUI-Update mehr als 40 ms dauert.

Dann gibt es die Antwort auf this Frage ich fragte http://programmers.stackexchange.com. Was besagt, dass Sie nicht mit vorzeitigen Optimierung beschäftigt sein sollten, wenn Sie es nicht brauchen. Vor allem, wenn es die Lesbarkeit von Code opfert.

So bringt mich das auf meine Frage: sollte nicht einfach aufrufen verwenden, wenn Sie einen anderen Thread kennen eine Steuer zugreift und nur, wenn Sie Ihre UI-Thread wissen, dass Stück Code zugreifen können und Sie finden dass es schneller laufen sollte, dass Sie prüfen sollten, ob ein Invoke erforderlich ist?

PS: Nach dem Korrekturlesen meiner Frage klingt es wirklich so, als würde ich schimpfen. Aber eigentlich bin ich nur neugierig, warum InvokeRequired anscheinend von vielen mehr-erfahrenen-als-ich-Programmierern überstrapaziert wird.

Answer 1

Sie nehmen die Dinge hier aus dem Zusammenhang. Die erste Frage you linked verknüpfte eine andere Frage, die speziell über das Schreiben einer thread-sicheren-Methode zum Zugriff auf ein UI-Steuerelement ging.

Wenn Sie keinen Thread-sicheren Zugriff auf ein UI-Steuerelement benötigen, weil Sie wissen, dass Sie es nicht von einem anderen Thread aktualisieren, dann sollten Sie diese Technik sicherlich nicht verwenden. Aktualisieren Sie einfach Ihre UI-Steuerung, ohne InvokeRequired oder Invoke zu verwenden.

Auf der anderen Seite, wenn der Anruf immer in einem anderen Thread als der UI-Thread stammt, verwenden Sie einfach Invoke, ohne vorher für InvokeRequired zu überprüfen.

Dies führt zu drei einfachen Regeln:

1. Wenn Sie die Steuerung nur aus dem UI-Thread aktualisieren, verwendet weder InvokeRequired noch Invoke
2. Wenn Sie die Steuerung aktualisieren, die von einem anderen Thread als der UI-Thread , nur Invoke verwenden.
3. Wenn Sie das Steuerelement sowohl vom UI-Thread als auch von anderen Threads aktualisieren, verwenden Sie Invoke in Kombination mit InvokeRequired.

Answer 2

In der Praxis neigen Menschen dazu, die gleiche Methode sowohl aus dem fremden als auch aus dem eigenen Thread aufzurufen. Das übliche Muster ist, dass die Methode selbst bestimmt, ob der Thread der besitzende Thread ist. Wenn dies der Fall ist, wird der Folgecode ausgeführt. Wenn dies nicht der Fall ist, ruft die Methode selbst Invoke dieses Mal auf.

Ein Vorteil davon ist, dass es den Code kompakter macht, wie Sie eine Methode im Zusammenhang mit der Operation statt zwei haben.

Ein anderer und wahrscheinlich wichtigerer Vorteil ist, dass es die Wahrscheinlichkeit verringert, dass die Cross Thread-Ausnahme ausgelöst wird. Wenn beide Methoden zu irgendeinem Zeitpunkt verfügbar wären und beide Threads eines der beiden auswählen könnten, bestünde die Chance, dass ein scheinbar legitimer Methodenaufruf eine Ausnahme auslöst. Auf der anderen Seite, wenn es nur eine Methode gibt, die sich an die Situation anpasst, bietet es eine sicherere Schnittstelle.