Multithreaded Server - Design Guidelines?
-
Ich will auch mal ØMQ in die Runde geworfen haben:
http://zeromq.org/
WEIT davon entfernt eine Magic Bullet für dein Problem zu sein, aber definitiv eine sehr interessante Library.
-
Ich hab gehoert, dass zeromq keine ordentlich cancelbare IO hat oder so aehnlich. Irgendwas war damit, was die Lib so ziemlich unbrauchbar macht.
-
Wo ist eigentlich das Problem? Du hast einen Thread-Pool mit I/O-Workern und einen Thread-Pool für deine jeweiligen Welten (also jede Welt sein Thread).
Jeder Welt-Thread ist mit einer Message-Queue mit den I/O-Threads verbunden, also eine 1-zu-1 Welt <--> Queue-Assoziation. Du assoziierst außerdem beim Verbindungsaufbau mit einem Client jedem Socket eine Welt (und damit auch die korrespondierende Queue) zu. Kommt jetzt eine Nachricht im I/O-Thread auf einem bestimmten Socket an, suchst du dir die Queue heraus und pushst die Nachricht. Der Welt-Thread wacht auf, wenn er merkt, dass was in der Queue ist und arbeitet die Message ab (evtl. sogar einfach lock-free zu gestalten, wenn nur 1 Thread pusht und ein andere popt).
Wenn in der Welt auch dann was passieren soll, wenn gerad kein Socket was gesendet hat, pushst du einfach selber von einem Scheduler-Thread (oder gar vom I/O-Thread) aus Nachrichten in die verschiedenen Welt-Queues, damit die dann irgendwas machen.
Das klingt für mich nach einfachem EVA-Prinzip.hustbaer schrieb:
Kontextwechsel sind aber gar nicht das Problem.
Das "Problem" hierbei ist dass der Scheduler jedem aktiven Thread gleich viel Zeit zuweist - statt jedem Prozess (bzw. Prozessgruppe) mit aktiven Threads gleich viel Zeit zuzuweisen.Aber wenn nun jedem Thread gleichviel Zeit zugewiesen wird, wird diese jeweils zugewiesene Zeitspanne doch auch mit wachsener Thread-Zahl immer kürzer (damit alle aktiven Threads mal dran sind); Bei gleichzeitig konstant bleibender Zeit für den context swap wird doch dann netto im Verhältnis zur Ausführungszeit eines Threads viel mehr Zeit mit dem swappen zugebracht, oder nicht? Alternativ wäre nur, ebenfalls die zugewiesenen Zeiten zu verlängern, mit dem Preis, dass manche Threads ewig unterbrochen sind. In beiden Fällen klingt das für mich in Sachen Skalierbarkeit katastrophal.
