Threads vs. Events

Algorithmen, Sprachunabhängige Diskussionen zu Konzepten, Programmiersprachen-Design
Antworten
jeanluc
Beiträge: 33
Registriert: Mo Apr 22, 2013 10:18 pm

Threads vs. Events

Beitrag von jeanluc » Mi Okt 30, 2013 8:16 pm

Ich habe so meine Probleme die Funktionsweise von eventbasierten Applikationen zu verstehen.
Siehe auch http://red-badger.com/blog/2013/01/29/t ... ent-based/

Den Ablauf einer Anfrage würde ich kurz so umreißen:

Client -> Server (eventbasiert) -> InQueue -> Worker -> OutQueue/Callback -> Client

So, das alles in einem Prozess. Oder auch nicht, wenn die Queue ausgelagert ist.

Daraus ergeben sich folgende Fragen:

- Wie werden die Sockets verwaltet ? Wird ein internes Array gehalten wo dann z.B. 10000 Sockets drinliegen ?
- Falls das so ist, muss der Socket ja erstmal warten, bis seine Anfrage asynchron abgearbeitet wird (Stichwort Timeout) ?
- Die Sockets sind im non blocking mode ? Wie ist das bei TCP/IP, das ist doch per default im blocking mode ?
- Erhält er die Antwort dann vom selben Socket, ergo dann auch vom selben Prozess ?
- Die eigentliche Arbeit des Workers wird im selben Prozess oder von einem anderen Prozess erledigt ?

Danke !

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8492
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Threads vs. Events

Beitrag von Xin » Do Okt 31, 2013 10:23 am

jeanluc hat geschrieben:So, das alles in einem Prozess. Oder auch nicht, wenn die Queue ausgelagert ist.

Daraus ergeben sich folgende Fragen:

- Wie werden die Sockets verwaltet ? Wird ein internes Array gehalten wo dann z.B. 10000 Sockets drinliegen ?
- Falls das so ist, muss der Socket ja erstmal warten, bis seine Anfrage asynchron abgearbeitet wird (Stichwort Timeout) ?
- Die Sockets sind im non blocking mode ? Wie ist das bei TCP/IP, das ist doch per default im blocking mode ?
- Erhält er die Antwort dann vom selben Socket, ergo dann auch vom selben Prozess ?
- Die eigentliche Arbeit des Workers wird im selben Prozess oder von einem anderen Prozess erledigt ?
Ich kann nicht behaupten, dass ich von dem Thema viel verstehen würde, da ich sehr wenig Erfahrung habe, was den Spaß mit den Server-Apps angeht.

Events sind in der Regel nur Strukturen, die an die Empfänger des Ereignisses kopiert. Heißt: Du hast eine Klasse "EventHandler", der Du eine Message - das Event - übergibst und Du hast Klassen, die sich über die Benachrichtigung freuen, wenn ein Event anliegt. Man registriert sich beim EventHandler zum Beispiel mit einer Callback-Funktion, der die EventMassage übergeben wird. Die Callback-Funktion kann nun entsprechend handeln. An der Stelle läuft noch nix mit Threads.

Mit meinem Webservice mache ich mir die Sache derzeit noch sehr leicht: Es gibt einen Listener, der in einem Loop auf Port 80 lauscht und falls da was ankommt einen Task erzeugt. Während der eine Task sich daran macht, den Socket zu übernehmen, geht der andere Task zurück in den Loop, um das "Ereignis" abzuarbeiten. Kommt während der Bearbeitung eine zweite Anfrage rein, so würden beide Anfragen parallel abgearbeitet, was zu Ärger führen könnte. Ich habe also derzeit mehrere Threads/Tasks.

Der "Listener" könnte die Anfrage auch bearbeiten, in eine Liste hängen und dem Worker ein Signal ("Event!") schicken, er möge sich drum kümmern. Die typische Situation im Restaurant. Keller nimmt Bestellung auf, gibt den Zettel in die Küche und drückt die Klingel. Sollte der Koch gerade Zeit haben, kann er in die Liste gucken und das Event abarbeiten. Hier laufen nur zwei Threads - ein Kellner, der die Bestellung annimmt und der Koch, der sie zubereitet. Im Gegenzug zum vorherigen gibt es nur einen einzelnen Worker-Thread, der seriell Bestellung für Bestellung durchgeht. Meine Thread-basierte Implementation stellt pro Kunde einen eigenen Koch ein und feuert ihn, nachdem das Essen fertig ist.
Trotzdem wirst Du - denke ich - mindestens zwei Threads benötigen, damit während der Worker gerade arbeitet, irgendwer neue Bestellungen/Events annehmen kann.

Bei dem Events liegen die Sockets dann als Message in einer Liste. Und manchmal müssen die auch warten. Und wenn der Server nicht hinterherkommt, die zu bearbeiten, gibt's auch schonmal Timeouts. So what? Wenn der Koch zu beschäftigt ist, dass er Dein Essen nicht kochen kann, dann stehst Du irgendwann auf und geht: Timeout.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

jeanluc
Beiträge: 33
Registriert: Mo Apr 22, 2013 10:18 pm

Re: Threads vs. Events

Beitrag von jeanluc » Fr Nov 01, 2013 11:49 pm

Gut, macht also nur Sinn, wenn man mehrere Prozesse startet.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8492
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Threads vs. Events

Beitrag von Xin » Sa Nov 02, 2013 8:21 am

jeanluc hat geschrieben:Gut, macht also nur Sinn, wenn man mehrere Prozesse startet.
Events laufen in einer Single-Prozesslösung auch: Man löst das Event aus und dann werden alle Empfänger der Reihe nach abgearbeitet. Objektorientierte Programmierung wäre da ein Beispiel für. Hier gibt es beim Methodenaufruf (Signal) aber immer nur einen Empfänger.
Threads und Events sind halt nichts, was man gleichwertig gegeneinander austauschen kann. Man kann sie aber kombinieren. Und wenn man sie kombiniert, lassen sich damit auch gut Server beschreiben, weil die Threads das Problem lösen, wenn Anfragen mal (kurzfristig) schneller reinkommen, als sie komplett verarbeitet werden können.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
darksider3
Beiträge: 347
Registriert: Fr Sep 14, 2012 6:26 pm
Wohnort: /dev/sda1
Kontaktdaten:

Re: Threads vs. Events

Beitrag von darksider3 » So Nov 03, 2013 10:15 am

Realbeispiel für Events: Du hast einen Baum mit 50 Äpfeln. Du willst alle Äpfel haben.. Aber Du kannst nur einmal für jeden Apfel "schütteln" und auch nur nacheinander, da Du ja nicht öfter auf einmal Schütteln kannst(bist ja allein).
Du musst also 50x schütteln, und der Baum wartet entsprechend auf dieses Event, das Du schüttelst, reagierst passend darauf, wie schon erwähnt, indem er die Äpfel "fallen" lässt.

Bei Threads kann man sich das in ungefähr so vorstellen, dass jeder Thread eine Person ist, die an dem Baum rüttelt. Also können z.B auch 4 Personen auf einmal schütteln, also auch 4 Äpfel auf einmal herunter befördern. Und zwar simultan.

Sorry, aber das klingt so verdammt Theoretisch, dass musste einfach sein..^^
effizienz ist, wenn ich ein loch bohre und hinterher mein nachbar auch ein bild aufhängen kann... ^^
Meine Homepage und der Microblog von mir :)
Live Life dont let Life Live You!
Am meisten Aktiv in Webentwicklung und PHP im Wiki

jeanluc
Beiträge: 33
Registriert: Mo Apr 22, 2013 10:18 pm

Re: Threads vs. Events

Beitrag von jeanluc » Mo Nov 04, 2013 3:55 pm

Ja das Problem ist aber, dass du Threads oftmals nur simuliert bekommst. Beispiel Twisted und Python. Brauchst also Stackless Python.

Bei node.js und Googles V8 ist es genauso. Also nix mit Threading, Prozesse und IPC sind gefragt.

In der Praxis ist es aber so, dass die Leute diese Bibliotheken single-threaded benutzen und denken das sei ganz toll so mit den Events (weil es die Homepages der Bibliotheken auch so vorgauckeln....).

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8492
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Threads vs. Events

Beitrag von Xin » Mo Nov 04, 2013 4:38 pm

jeanluc hat geschrieben:(weil es die Homepages der Bibliotheken auch so vorgauckeln....).
Es wäre mir neu, dass ein Hersteller auf seiner Website über die Nachteile seines Produktes referiert oder erklärt, wann man sein Produkt nicht verwenden sollte.
Bedienung mit höchster Effizenz (die jedes Jahr noch höher effizient wird) - und das kann ja durchaus auch stimmen, aber dass die Software so wenig intuitiv ist, dass sie ohne Schulung überhaupt nicht zu bedienen ist, steht da in der Regel nicht.
Für alles was nicht funktioniert, gibt es Alternative, alternativ Innovationen, vollkommen neue Herangehensweisen, aber keiner schreibt, dass der direkte Weg halt nicht zur Verfügung steht.

Kurz: Die Webseite des Herstellers gibt ein Indiz dafür, wofür man das Produkt im Idealfall benutzen kann. Hat man einen anderen Fall, sollte man mit allem rechnen und sich wundern, wenn es trotzdem funktioniert. :-)
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Antworten