Wieso lassen so viele Programme den Benutzer so lange warten?
-
die Frage ist aber, wie viel vom Parallelisierungsproblem auf die Kappe der Programmiersprachen selbst geht.
Programmiersprachen wie C++ stammen aus Zeiten, als Parallelisierung noch nicht das Thema war. Ergo keine optimale Formalisierung von nebenläufigen Vorgängen.
ich kann mir vorstellen, daß sich das in Zukunft nolens volens ändern wird. Sprachmittel zur einfachen Modellierung von nebenläufigen Prozessen werden vielleicht mal das feature sein, so wie heute Klassen und geschweifte Klammern. erlang fällt mir hier spontan ein.
-
Tja, die perfekte Art (sofern sie exisiert) parallele Ausführungsmöglichkeiten zur Verfügung zu stellen ist halt (noch?) nicht gefunden worden.
Ist aber ein aktives Forschungsgebiet.
-
!rr!rr_. schrieb:
die Frage ist aber, wie viel vom Parallelisierungsproblem auf die Kappe der Programmiersprachen selbst geht.
Programmiersprachen wie C++ stammen aus Zeiten, als Parallelisierung noch nicht das Thema war. Ergo keine optimale Formalisierung von nebenläufigen Vorgängen.
ich kann mir vorstellen, daß sich das in Zukunft nolens volens ändern wird. Sprachmittel zur einfachen Modellierung von nebenläufigen Prozessen werden vielleicht mal das feature sein, so wie heute Klassen und geschweifte Klammern. erlang fällt mir hier spontan ein.
Gabs alles Schon in Lisp. Ada faellt mir ein. Haskell hat interessante Ansaetze. Und zu guter Letzt: Vhdl bzw. FPGAs.
-
immer gibt es alles schon Jahrzehnte vorher in lisp ... so macht das Diskustieren keinen Spaß
-
Dravere schrieb:
@Eisflamme,
Mach einfach mal ein paar Beispiele durch, was Multithreading betrifft und dann wirst du schnell mal begreifen, wieso dies nicht alles so einfach ist.Also ich muss aber sagen, mit std::future und std::async geht das meiste schon ganz nett, solange man keinen sehr abhängigen Algorithmus hat. (Was bei Applets und Bildern ja nicht der Fall ist.)
Wahrscheinlich hatten alle anderen Sprachen das schon lange, aber ich gebe die Hoffnung nicht auf, dass der C++11 Standard da etwas an der Schraube dreht. Ich jedenfalls werde mir jetzt öfter Gedanken machen, ob man etwas nicht parallelisieren kann.
-
inflames2k schrieb:
Es bietet sich halt oft an, längere Operationen nicht in Asynchron auszuführen. Zum einen wie schon genannt, da es die Entwicklung vereinfacht, zum anderen aber auch, da es für den Benutzer am Ende egal ist, ob er die Anwendung nicht verwenden kann, weil sie für den Zeitraum nicht reagiert, oder weil die relevanten Steuerelemente gesperrt sind.
falsch. wenn eine anwendung nicht mehr reagiert - also die gui nicht mehr neu gezeichnet wird, z.b. wenn man das fenster verschiebt - nimmt er an, die anwendung ist abgeschmiert.
unfassbar dass im jahre 2012 offenbar immer noch leute single threaded GUIs schreiben.
-
lolhehe schrieb:
unfassbar dass im jahre 2012 offenbar immer noch leute single threaded GUIs schreiben.
Die GUI selbst ist doch eigentlich immer singlethreaded. Nur gewisse langdauernde Arbeiten werden ausgelagert.
Oder gibt es ernstzunehmende GUI toolkits, bei denen die grafische Oberfläche selbst in mehreren threads läuft?
-
lolhehe:
Ich muss sagen, das wundert mich genau auf der Ebene eben auch... und ich habe jetzt selbst ein paar asynchrone Dinge implementiert und finde das in den meisten Fällen überhaupt nicht schlimm.Einfach einen Workerthread nehmen und dem n Task zuteilen und bei Abarbeitung eben das Ergebnis die GUI schreiben. Wechselt Benutzer etwas oder tut etwas, weswegen der Task abgebrochen wird, wird der Task abgebrochen, gut ist. Und wenn man mit Ergebnissen weiterarbeiten möchte bzw. der User das können soll, blockiert man die Weiterarbeitung, sodass nicht gleichzeitig ein Task und das Arbeiten mit den Ergebnissen geschehen kann. Und soll es das, identifiziert man auch für Benutzer die Tasks eindeutig, damit er das jeweilige Ergebnis auswählen kann.
Aber irgendwie scheint das nicht so der Stand zu sein, keine Ahnung. Ich merk ja, das kann schnell kompliziert werden, aber das sehe ich mehr bei Echtzeit-Interaktion von vielen Threads, die unterschiedliche Dinge tun mit sehr vielen Abhängigkeiten, als bei ner GUI, wo man Tasks auslagert.
-
Also asynchron und multithreaded sind nicht dasselbe.
-
Hm und wie setzt man Asynchronität ohne Multithreading um?
-
Eisflamme schrieb:
Hm und wie setzt man Asynchronität ohne Multithreading um?
na eins nach dem anderen und immer schön abwechseln
-
Ja eben, aber das Verhalten wird bei Einprozessor-Maschinen ja sowieso bei Multithreading genutzt. Multithreading heißt nicht echte Parallelität. Deswegen verstehe ich nicht so recht, was die Unterscheidung zwischen Asynchronität und Multithreading soll.
Oder einfach, weil Asynchronität in diesem Fall als einfacher Spezialfall gemeint ist, den man eben doch alle Nase lang einsetzen kann?
-
Es gibt für manche Dinge asynchrone APIs, die mit Threads nix zu tun haben.
In Qt kann ich zB: mit Sockets arbeiten und die schicken mir ein Signal wenn etwas interessantes passiert (gibt was zu lesen zB.). Dafür muß ich mich nicht mit Threads rumschlagen und die Gui bleibt trotzdem aktiv. Außer natürlich man macht in dem Socket-Slot was extrem langwieriges. Das vereinfacht halt einfach die Implementierung enorm.
-
@Eisflamme
Ein Thread ist ein Thread, ganz klassisch mit eigenen Registern, eigenem Program-Counter, und das alles wird schön vom System gemacht, muss man sich nicht selbst drum kümmern.
Wenn man mehrere davon haben kann, nennt man das Multithreading.Wenn ich dagegen z.B. nen Messagepump habe und über diesen Benachrichtigungen empfange wenn diverse asynchrone IOs die ich losgetreten habe abgeschlossen wurden, dann nennt man das nicht Multithreading.
-
Okay.
-
lolhehe schrieb:
inflames2k schrieb:
Es bietet sich halt oft an, längere Operationen nicht in Asynchron auszuführen. Zum einen wie schon genannt, da es die Entwicklung vereinfacht, zum anderen aber auch, da es für den Benutzer am Ende egal ist, ob er die Anwendung nicht verwenden kann, weil sie für den Zeitraum nicht reagiert, oder weil die relevanten Steuerelemente gesperrt sind.
falsch. wenn eine anwendung nicht mehr reagiert - also die gui nicht mehr neu gezeichnet wird, z.b. wenn man das fenster verschiebt - nimmt er an, die anwendung ist abgeschmiert.
unfassbar dass im jahre 2012 offenbar immer noch leute single threaded GUIs schreiben.
Kommt drauf an, im normalfall entwickle ich auch Multi-Threaded Anwendungen. Aber eben nur soweit es Sinn macht. - Bei Anwendungen wo der Benutzer während der Aktion nichts machen können darf lagere ich das nicht extra in eine Asynchrone Operation aus.
-
und genau das verstehe ich nicht. du musst dem benutzer doch zumindest ein feedback geben, dass eine aktion läuft und er bitte warten soll, z.b. indem du eine progressbar anzeigst oder einfach nur ein "bitte warten".
wenn du das aber nicht tust und deine lange operation im GUI thread läuft, legst du damit alle repaints der GUI lahm. der benutzer kann hier nicht mehr unterscheiden zwischen "lange operation läuft noch" und "anwendung hat sich aufgehängt".
ich sage ja gar nicht, dass man jede gui anwendung total toll parallelisieren soll. aber zumindest sollte man lange operationen nicht im GUI thread ausführen sondern in einem worker thread + den user entsprechend darauf hinweisen, dass eine operation läuft, die evtl. etwas länger dauert.
das ist wahrlich keine rocket science...
-
Klar, in gewisser Hinsicht stimmte ich dir voll und ganz zu. Andererseits kann man jedoch schon in der Dokumentation auf Punkte eingehen, dass die Anwendung z.B. bei Laden von großen Datenmengen aus der DB so lang der Abruf dauert nicht bedienbar ist.
-
kommt halt auf deine kundschaft an. wenn die vollends schmerzbefreit ist, könntest du damit durchkommen.
aber mittlerweile hat selbst SAP erkannt, dass GUIs dem anwender auch gefallen sollten. UX wird mehr und mehr zu kernthema in der frontend entwicklung.
-
Eisflamme schrieb:
Hm und wie setzt man Asynchronität ohne Multithreading um?
Schon mal was von DMA gehoert? Laeuft asynchron genau wie viele andere Prozesse auf dem PC ganz ohne Multithreading, eben weils von der Hardware unterstuetzt wird.
