Einzelnen Beitrag anzeigen

Furtbichler
(Gast)

n/a Beiträge
 
#3

AW: frage zu threads und timer

  Alt 9. Dez 2013, 09:05
Stell Dir einfach vor, deine 4 Threads sind 4 Personen, die gleichzeitig irgend etwas machen, vermutlich in einer Schleife.

Also: 1 Koch, der auf Bestellungen wartet, diese zubereitet und dann in der Durchreiche abstellt und vermutlich irgend eine Bimmel betätigt.

1 Gast, der Platz nimmt, Hunger bekommt oder hat, auf einen Ober wartet, eine Bestellung aufgibt, auf das Essen wartet, isst, rülpst, bezahlt und geht.

1 Ober, der Bestellungen vom Gast aufnimmt, diese zur Küche bringt und (wie?) an die Küche übermittelt.

1 Ober, der die fertig gekochten Gerichte aus der Küche zum Gast bringt, abräumt und ggf. abkassiert.

1 Inhaber, der blöd in der Ecke rumhängt, sich einen Cocktail nach dem anderen hinter die Binde knallt und mit der Barfrau schäkert.

Gut, der letzte muss jetzt nicht synchronisiert werden, aber da kann man lernen, das es Threads gibt, die Überflüssig wie ein Kropf sind.

Was ich meine sind die Schnittstellen zwischen den Threads: Würde der Koch nach dem Kochen eines Gerichts warten, bis dieses abgeholt wird, würden sich die Bestellungen vermutlich stapeln, oder man bräuchte mehrere Köche. Er könnte auch alle paar Sekunden zur Bestellannahme gehen und schauen, ob es was neues zu tun gibt. Besser, aber auch blöd, weil er dann auch mal umsonst schauen geht. Was ist also der beste Weg?

Wenn der Ober so lange vor dem Gast auf und ab wippt, bis dieser sich entschieden hat, ist das auch keine gute Sache, denn der Gast wird dem Ober vermutlich irgendwann eins mit der Karte übersemmeln oder gleich zum Inhaber gehen, der dann doch eine gewisse Funktion hat...

Die Lösung ist die 'asynchrone Kommunikation' (Bimmel, 'Her Ooober', 'Zahlen bitte') sowie Queues (Essensausgabe, Bon-Leiste usw).

Lustig ist, das in einem Restaurant ein Restaurantleiter etwaige Staus auflöst und für einen reibungslosen Ablauf sorgt. Ein ähnlicher Controller würde in kritischen Systemen die Threads und Übergaben auch überwachen (overflows etc.) und ggf. eingreifen.

Ein Thread reagiert auf Events, und löst selber Events aus, wenn er einem anderen Thread mitteilen will, das dieser weiterarbeiten kann. Der Thread nimmt Aufträge aus einer Queue, führt diese aus und schreibt sein Ergebnis wieder in eine Queue usw.

Der Controller prüft die Queues und reagiert, wenn diese so groß werden: Dann ist ein Thread entweder abgeschmiert (gaaanz schlecht) oder kommt mit der Arbeit einfach nicht hinterher (zweiten Thread starten: Fertig). Oder das System ist dann einfach überlastet: Eine Küche mit zwei Herden (=limitierte Resourcen) ist auch mit 20 Köchen nicht in der Lage, mehr als 30 Personen zu bewirten...
  Mit Zitat antworten Zitat