Warum müssen / sollten UI-Frameworks Singlethreading sein?

Allgemein verwandte Fragen wurden bereits gestellt:

Warum sind die meisten UI-Frameworks Single-Threaded?.Sollen alle ereignisgesteuerten Frameworks Singlethread-Frameworks sein?

Aber die Antworten auf diese Fragen lassen mich in einigen Punkten immer noch unklar.

Der Fragesteller der ersten Frage fragte, ob Multithreading die Leistung verbessern würde, und die Antwortenden gaben meistens an, dass dies nicht der Fall sein würde, da es sehr unwahrscheinlich ist, dass die grafische Benutzeroberfläche der Engpass in einer 2D-Anwendung auf moderner Hardware ist. Aber das scheint mir eine hinterhältige Debattiertaktik zu sein. Sicher, wenn Sie Ihre Anwendung sorgfältig so strukturiert haben, dass nichts anderes als Benutzeroberflächenaufrufe auf dem Benutzeroberflächenthread ausgeführt werden, entsteht kein Engpass. Aber das könnte eine Menge Arbeit kosten und Ihren Code komplizierter machen, und wenn Sie einen schnelleren Kern hätten oder UI-Aufrufe von mehreren Threads ausführen könnten, wäre es vielleicht nicht wert.

Ein häufig empfohlenes Architekturdesign besteht darin, Ansichtskomponenten zu haben, die keine Rückrufe haben und nichts außer möglicherweise ihren Nachkommen sperren müssen. Können Sie unter einer solchen Architektur nicht zulassen, dass ein Thread Methoden für Anzeigeobjekte mit objektspezifischen Sperren aufruft, ohne Angst vor einem Deadlock?

Ich bin weniger zuversichtlich in Bezug auf die Situation mit UI-Steuerelementen, aber solange ihre Rückrufe nur vom System aufgerufen werden, warum sollten sie @ verursacheBesonder Deadlock-Probleme? Wenn die Rückrufe zeitaufwändig sind, werden sie an einen anderen Thread delegiert, und dann sind wir wieder in der Mehrfach-Thread-Situation.

Wie viel von dem Vorteil einer Multithread-Benutzeroberfläche würden Sie erhalten, wenn Sie nur den Benutzeroberflächenthread blockieren könnten? Weil verschiedene aufkommende Abstraktionen über Async dies ermöglichen.

Fast die gesamte Diskussion, die ich gesehen habe, geht davon aus, dass Parallelität mit manueller Sperre behandelt wird, aber es besteht ein breiter Konsens darüber, dass manuelle Sperre in den meisten Kontexten eine schlechte Möglichkeit ist, Parallelität zu verwalten. Wie ändert sich die Diskussion, wenn wir die Nebenläufigkeitsgrundelemente berücksichtigen, von denen die Experten raten, mehr zu verwenden, z. B. Software-Transaktionsspeicher oder das Vermeiden von gemeinsam genutztem Speicher zugunsten der Nachrichtenübermittlung (möglicherweise mit Synchronisierung, wie unterwegs)?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage