Multithreading

[byto]

Man kann sich auch von hinten durch die Brust ins Auge schießen, nur um zu beweisen das es möglich ist. Sinn macht es aber dadurch noch lange nicht.

Klar kann man sich irgendwie auch in der GUI Programmierung ohne Threads behelfen. Ändert aber nichts an der Tatsache, das moderne UI-Frameworks ALLE Multithreading benutzen. Wer also heutzutage GUIs programmiert, wird zwangsläufig auf kurz oder lang mit Multithreading zu tun bekommen (egal ob 1 oder 2 Kerne). Wenn nicht, dann macht er was Grundlegendes falsch (man siehts leider noch viel zu oft, dass Actions nicht in Threads ausgelagert werden).

Oder kann mir jemand ein aktuelles UI-Framework nennen, dass gänzlich ohne Multithreading arbeitet? Mir fällt spontan nur Javascript ein (damit könnte man ja auch ein UI im Browser bauen), aber das möchte ich hier mal aussen vor lassen (zu speziell).

[hustbaer]

@byto:
Es gab GUIs lange bevor es Betriebssysteme gab, die einem das Multitasking/-threading abnehmen.
Diese GUIs waren auch sinnvoll.

Und selbst heute noch macht es bei einigen Tools wenig Sinn Multitasking/-threading zu verwenden, weil einfach nirgendwo Wartezeiten entstehen die ausreichend gross wären.

Beispielsweise ein Text-Editor, Taschenrechner o.ä.

@Tyrdal:
Huch?

[;fricky]

byto schrieb:

Wie willst Du z.B. einen Datenbankzugriff in kleine Happen einteilen?

anfrage abschicken und dann in kleinen abständen abfragen, ob die antwort schon da ist. ginge z.b. unter windows mit dem SetTimer()-befehl und in der wndproc hätteste dann regelmässig einen event, bei dem du die DB pollen könntest.
btw, der timer-mechnismus unter win braucht keine separaten threads.

Tyrdal schrieb:

Du könntest ja statt Threads Prozesse nehmen.

ein prozess braucht mindestens einen thread, damit er was tun kann. damit hätteste nichts gewonnen.

[hustbaer]

das moderne UI-Frameworks ALLE Multithreading benutzen

Benutzen? Wo?
Oder meinst du unterstützen?

[byto]

hustbaer schrieb:

@byto:
Es gab GUIs lange bevor es Betriebssysteme gab, die einem das Multitasking/-threading abnehmen.
Diese GUIs waren auch sinnvoll.

Vor 20 Jahren waren die mal sinnvoll, ja.

Naja, solche Grundsatzdiskussion sind ziemlich sinnlos. Aber wenn man das hier liest, muss man sich wohl nicht wundern, dass man noch so häufig grottigen GUI-Code sieht.

[Zeus]

hustbaer schrieb:

das moderne UI-Frameworks ALLE Multithreading benutzen

Benutzen? Wo?
Oder meinst du unterstützen?

IMHO kapselt Java/Swing die Hauptschleife in einen eigene Thread.

[byto]

Ja, der so genannte EDT (Event Dispatch Thread). Aber wenn der User z.B. auf einen Button drückt, dann werden die ActionListener eben auch im EDT aufgerufen, es sei denn Du machst explizit einen neuen Thread auf.

Es gibt ansonsten diverse Stellen, wo Threads verwendet werden, siehe z.B. javax.swing.Timer oder SwingUtilities#invokeLater() (beides Java Swing) oder die Eclipse Job API (Eclipse RCP).

[hustbaer]

byto schrieb:

hustbaer schrieb:

@byto:
Es gab GUIs lange bevor es Betriebssysteme gab, die einem das Multitasking/-threading abnehmen.
Diese GUIs waren auch sinnvoll.

Vor 20 Jahren waren die mal sinnvoll, ja.

Naja, solche Grundsatzdiskussion sind ziemlich sinnlos. Aber wenn man das hier liest, muss man sich wohl nicht wundern, dass man noch so häufig grottigen GUI-Code sieht.

Du übertreibst einfach ziemlich, daher kommt soviel Gegenwind.

Klar macht es sehr oft Sinn Threads in einem GUI Programm zu verwenden.

Aber nicht in allen GUI Programmen, und die GUI Frameworks die ich so kenne unterstützen Threading mehr schlecht als recht, und verwenden selbst auch keinerlei Threads.

BTW: Swing kenne ich BTW nicht. Ich glaube auch gern dass manche GUI Toolkits Threads (sichtbar für den User-Programmer - sonst zählt es IMO nicht) verwenden. Nur manche != alle.

Deine Aussage ist also übertrieben, und deine "Begründung" ist IMO einfach falsch.

Natürlich kannst du dir gerne denken, dass alle hier keine Ahnung haben und stümperhafte GUI Programmierer sind.
Oder du könntest einfach zuzugeben, dass du ein wenig übertrieben hast. Nennt dich ja schliesslich keiner doof deswegen.

p.S.: es gibt auch andere Möglichkeiten als Threads, Dinge asynchron zu machen. Siehe fricky's Beitrag. Oder denk bloss mal an die verschiedenen Möglichkeiten wie man asynchrones IO machen kann. All das lässt sich auch in einem GUI Programm machen. Ich verwende da auch viel lieber Threads, weil ich damit einfach schneller bin. Muss man aber nicht.

[byto]

Lange Operationen gehören bei GUI Anwendungen in Worker-Threads, damit die GUI nicht einfriert. Das war meine Behauptung.
Wenn Du diese als falsch ansiehst, dann ist das Dein gutes Recht. Das ist schließlich ein freies Land.

[volkard]

byto schrieb:

Lange Operationen gehören bei GUI Anwendungen in Worker-Threads, damit die GUI nicht einfriert. Das war meine Behauptung.

Hier stand eine kleine Klarstellung, die nicht im Detail wichtig ist.

[byto]

Ja Volkard, Du hast Recht und ich hab meine Ruhe.

[@byto]

Manche geben auch einfach zu, wenn sie unrecht hatten.