Multithreading

zusammenfassung schrieb:

hier gibts ne ganze menge klugscheißer und erbsenzähler

muss manchmal sein und manchmal auch nicht. hauptsache, wir haben alle spass dabei.

byto schrieb:

Manche geben auch einfach zu, wenn sie unrecht hatten.

Die, die meinen, dass man für GUIs Multithreading braucht?

Grohool

;fricky schrieb:

rapso schrieb:

deswegen macht ein extra thread auf applikationsseite keinen sinn wenn man damit auf einem single-core system performance erhalten will.
arbeitest du auf nem embeded system, kann das sehr wohl einen sinn machen.

auch nicht. pro zeiteinheit kann 'ne CPU nur soundsoviele befehle ausführen. mit multithreading auf nur einer CPU ist gewinnt man luxus für programmierer (dass die schöne schleifen coden können), aber niemals geschwindigkeit.

Eine CPU wird durch einen thread aber in der Regel nicht voll ausgelastet, z.B. wenn daten aus dem Arbeitsspeicher geladen werden müssen muss der Prozessor warten. Manche Prozessoren können in so einem Fall dann mit einem zweiten thread die Wartezeit überbrücken.

hustbaer

;fricky schrieb:

hustbaer schrieb:

ganz ohne multithreading/multitasking müsste man auf die platte warten.

auch ohne multitasking kann man die wartezeit nutzen, um was anderes zu machen. das ist nur etwas aufwendiger (schrieb ich ja bereits).

nein fricky. wie nennt man es noch schnell im englischen wenn man mehrere dinge gleichzeitig macht? hmmm....
achja: multitasking

du ziehst hier vollkommen willkürlich eine grenze, die da IMO nicht hingehört.

Grohool schrieb:

Eine CPU wird durch einen thread aber in der Regel nicht voll ausgelastet, z.B. wenn daten aus dem Arbeitsspeicher geladen werden müssen muss der Prozessor warten. Manche Prozessoren können in so einem Fall dann mit einem zweiten thread die Wartezeit überbrücken.

ok, ein gut gemachtes multitasking-system bringt die CPU in einen stromsparmodus, wenn kein thread was zu tun hat. ich hab' z.b. den 'TNKernel' (auf meinem LPC23XX-system) dahingehend erweitert, dass er keine low-priority 'idle-loop' durchläuft, wenn nichts zu tun ist, sondern die CPU abschaltet, bis der nächste interrupt eintrifft (also mindestens ein timer-interrupt, der den scheduler antickert). das ist natürlich auch ein vorteil eines multitasking-systems, der hier bisher nicht genannt wurde. aber mal angenommen, du hast ein system, bei dem ständig irgendwelche daten durchgepumpt werden und bei dem energieverbrauch egal ist, dann biste ohne preemptives multitasking besser dran, weil die ganze rechenzeit für nützliche dinge benutzt wird, und nicht z.b. für's umschalten von tasks usw.

byto

ownpwnd schrieb:

byto schrieb:

Manche geben auch einfach zu, wenn sie unrecht hatten.

Die, die meinen, dass man für GUIs Multithreading braucht?

Alle mir bekannten aktuellen UI Frameworks sind multithreaded: QT, WPF, Cocoa, SWT, Swing, ... aber laber ruhig.

byto schrieb:

ownpwnd schrieb:

byto schrieb:

Manche geben auch einfach zu, wenn sie unrecht hatten.

Die, die meinen, dass man für GUIs Multithreading braucht?

Alle mir bekannten aktuellen UI Frameworks sind multithreaded: QT, WPF, Cocoa, SWT, Swing, ... aber laber ruhig.

Und? Soll das dein Beweis sein, dass man Multithreading für GUIs braucht?

byto

ownpwnd schrieb:

byto schrieb:

ownpwnd schrieb:

byto schrieb:

Manche geben auch einfach zu, wenn sie unrecht hatten.

Die, die meinen, dass man für GUIs Multithreading braucht?

Alle mir bekannten aktuellen UI Frameworks sind multithreaded: QT, WPF, Cocoa, SWT, Swing, ... aber laber ruhig.

Und? Soll das dein Beweis sein, dass man Multithreading für GUIs braucht?

Warum sollte ich Dir irgendwas beweisen? Hast du schon irgendwas Konstruktives beigetragen?

Schleife:
    Bild in Grafikspeicher schreiben
    Tasten Interrupts lesen
    Bild entsprechend anpassen

GUI fertig, ohne Threads

Tyrdal

Schleife:
  Bild in Grafikspeicher schreiben
  Tasten Interrupts lesen
  Lange Berechnung  
  Bild entsprechend anpassen

Während der langen Berechnung wird die Gui nicht aktualisiert, gaaaaanz toll.

byto

Eben. Der Event Dispatcher der GUI muss in irgendeiner Weise halbwegs flott neue Events verarbeiten. Das kann er schlecht, wenn eine lange Operation den selben Thread blockiert. Deswegen muss man in aktuellen UI-Frameworks lange Operationen in einen eigenen Thread auslagern. Tut man das nicht, friert die GUI bei langen Operationen ein.

volkard

byto schrieb:

Eben. Der Event Dispatcher der GUI muss in irgendeiner Weise halbwegs flott neue Events verarbeiten. Das kann er schlecht, wenn eine lange Operation den selben Thread blockiert. Deswegen muss man in aktuellen UI-Frameworks lange Operationen in einen eigenen Thread auslagern. Tut man das nicht, friert die GUI bei langen Operationen ein.

ALso hast DU schonmal eingesehen, daß "Von daher brauchst Du bei GUI Anwendungen immer Multithreading, egal ob ein oder mehrere Kerne." in dieser ALlgemeinheit falsch war.
Außerdem bist bestimmt Du am Rande der Erkenntnis, daß fähige Programmierer, naja, alle nicht vollkommen unfähigen Programmierer, die langen Operatopnen aufteilen können in kleine Happen, indem man alle 10ms yield() aufruft.

byto

Wie willst Du z.B. einen Datenbankzugriff in kleine Happen einteilen? Im übrigen verstehe ich nicht, was Dein yield() machen soll. Mein yield() gibt die Kontrolle an andere Threads ab - bringt also gar nix, wenn die Anwendung nur in einem Thread läuft.

Aber um dieses mühselige Thema endlich zu beerdigen: Ja Ihr habt recht, ich habe mich nicht 100% korrekt ausgedrückt. Man kann auch ohne Multithreading GUI Logik programmieren, wenns auch total sinnfrei ist.

Aber was wäre ein Forum wie dieses, ohne auf Sinnfreiheit zu beharren, nur um Recht zu behalten.

Tyrdal

Du könntest ja statt Threads Prozesse nehmen. Bei nem OS mit preemptiven Multitasking brauchste dann auch kein yield mehr. Aber das ist eher ungemütlich auf exotischen Systemen wie MS Windows, weil dort die Prozeßerzeugung so lahm ist.

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?

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.