Mir ist jetzt nicht ganz klar, warum mir dabei threads nicht helfen sollten?
Ich weiss es auch nicht, weil ich dein Konzept nicht kenne.
Deswegen ja auch die Frage, auf was Du Wert legst bei deiner Implementierung. Um was geht es Dir.
- Funktionalitaet des Programmes ?
- Performance ?
- Es mal mit Qt implementiert haben
Alles IMHO valide Motivationen, so ein programm zu schreiben. Aber alle diese Motivationen sollten einen unterschiedlichen einfluss auf das Konzept haben.
2. frage, um was geht es hier, den Server oder Client ? Die haben unterschiedliche Anforderungen, koennte also sein das es durchaus unterschiedliche konzepte gibt.
Performance-Problem iss dabei bissi tiefgruendiger. Mal auf den Server bezogen:
Mal Bezug auf "NetzwerkProgrammierung mit Linux", das Buch mein ich, da werden alle 3 Parallelisierungsarten die fuer Sockets in Frage kommen, verglichen.
- Selectiver Server
- Multithreaded Server mit Pool / ohne Pool
- Multiprocessing server mit Pool / ohne Pool (prefork)
Die Frage was ist Performanter. kann man ned so einfach beantworten. Ausser, dass die entscheidung multithread oder multiprocess nicht von der Performance abhaengig gemacht werden sollte (multiprocessing iss immer kleinwenig langsamer), multiprozessing hat andere Vorteile.
Aber denk mal das faellt hier raus.
Bleibt Selectiver Server vs multithreded.
der Selective server frisst am wenigsten ressourcen
Bei nichtkonkurrierenden anfragen hat er die kuerzesten reaktionszeiten.
Aber sobald mehrere anfragen kommen, gibts quasi ne warteschlange ... das heisst bei nem selektiven server gewinnt immer irgend nen client, waehrend andere quasi warten. Aber das kann man auch in Grenzen halten. Der selektive server ist auch in der summer schneller, wenn der multithreaded server nicht auf mehrer kerne zurueckgreifen kann (vorrausgesetzt man implementiert das multithreading richtig).
Multithreading bringt Dir also bei so nem Server 2 Vorteile:
Nutzung von mehreren Kernen möglich, wenn die Bedingungen stimmen.
Geichmaessigere Aufteilung der ressourcen (rechenzeiten) bei mehreren clients gleichmaessig.
Beantwortet die Frage hoffentlich:
Muss ein Server der mehrere Connections gleichzeitig bedient, undbedingt multithreaded sein ?
Nein !
Die Frage, warum wird multithreading und sockets immer gern beschrieben, und warum sind die meisten Beispiele von "Server" multihreaded ?
Weil Assynchrone socket-programmierung im CStyle den meisten das Gehirn sprengt. Es ist halt ned wirklich intuitiv. Die synchrone programmierung ist viel intuitiver, Aber deren "blockierung" kriegt man nur durch multithreading weg.
Aber die QT bietet Dir halt ne intuitive schnittstelle zur assynchronen programmierung in singlethreadumgebungen an (Signale/Slots).
Also was bleiben weiter fuer Gruende fuer multithreading ?
- du willst mehrere kerne nutzen. Klar.
- du hasst ne zwingend blockierende schnittstelle, willst aber nen nichtblockierendes Interface anbieten.
- Du hasst eine langwierige operation die nicht rational unterbrechen kannst und die lange genug laeuft als das man sie als blockierend betrachten kann, willst aber nen nichtblockierendes Interface anbieten.
mehr eigentlich nicht ...
Wie gesagt, ob Multithreading fuer dich das richtige Konzept ist, entscheiden Deine Anforderung, sollten zumindest.
Selbst mit multithreading gibts mehrere konzepte ...
wieder der Server z.b.:
- ein serverthread, fuer jeden Client gibts ein Thread, Socket(bidirektional) -> DB -> DatenProzesser -> Socket(Antwort) lauft im selben Thread. (der Klassiker -> Datensource -> Senke )
Konsequenz: Die Kommunikation zwischen sever und 1.Client in sich ist zwingend sequentiell (obwohl nen Socket schon bidirektional und duplex sein kann)
oder
- ein serverthread zur verwaltung, fuer jeden client ein sende und ein Empfangssthread, ein Zentraler Thread zur datenverarbeitung, ein thread fuer DB zugriffe. "Wilde" Kommunikation der Threads untereinander.
oder oder ....
Was das beste ist fuer Dich, kommt ganz auf deine Anforderungen an ...
@solarix
wo die Hauptapplikation und der Thread die Jobs/Resultate über MT-sichere Stapel austauschen
Vollkomment klar, die MsgLoop implementiert dir den Nachrichtenkanal threadsicher und an sich ziemlich peroformant.
Macht aber nur sinn wenn du es auch brauchst.
Idealer weisse funtionieren Threads fuer sich ....
du bereitest die daten fuer den Thread auf, du startest den thread. Wenn der Thread fertig ist, gibts ne Nachricht, und der thread beendet sich dann gleich. Die resultate liegen dann an ner vordefinierten stelle.
Damit hasst du genau 3 kommunikations- und Synchronisationspunkte:
den Start, das Ende, und den nen Abbruch mittendrinn, falls notwendig.
das Ende kannst ueber die Msgloop des mainthreads handeln .... die existiert ja eh.
fuer die anderen 2 punkte willst so nen "stapel" einrichten und verwalten (ok, macht Qt fuer dich, aber die kosten hasst trotzdem) ... starten geht automatisch meist ... und fuers abbrechen brauchst eigentlich nur ne atomare variable, oder nen Event oder wenn mies implementierst, ne normale variable mit Mutex geschuetzt...
Bei den oben genannten Modellen ... das lineare Datensink Modell ...
Du hasst NULL kommunikation zwischen den threads. Starten geht ueber den startthread vom der Socketkopie getriggert, das beenden kannst den mainthread ueber seine (die einzige) Loop mitteilen, wenn er eine hat.
das abbrechen geht ueber die Condition , das beenden ueber das kommunikationsprotokoll an sich... warum sollt ich da loops gebrauchen ?
Das "inperformante" an der QTLoop ist der ganze MetaClass mechanismuss, der hintendranhaengt, wenn du nachrichten ueber nen thread hinweg schickst ... damit du nicht nur Simple daten in den Signalen schicken kannst sondern auch komplette strings, maps, Variants ..... und das brauchst du eben nicht zwingend.
Bei dem Konzept mit der "wilden Kommunikation" ueber threadgrenzen hinweg, geb ich dir recht, koennen loops ne richtige Hilfe sein. Da brauchst soweiso einen aehnlichen mechanismus zur Synchronisation!
Solltest aber im Hinterkopf haben, das signale / Slots ueber Threadgrenzen immer ne kopie machen durch den Metaclass Mechanismus (die aber meistens durch implizietes sharing abgefangen wird ^^ )
Ciao ...
