Fibers und Thread-Pools

Design Patterns, Erklärungen zu Algorithmen, Optimierung, Softwarearchitektur
Forumsregeln
Wenn das Problem mit einer Programmiersprache direkt zusammenhängt, bitte HIER posten.
Benutzeravatar
Krishty
Establishment
Beiträge: 6736
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Fibers und Thread-Pools

Beitrag von Krishty » 02.03.2016, 17:41

Keine Ahnung, aber da es mit File Handles und Events auch geht werden sie sich da was überlegt haben :) Schon gut, bin ja wieder weg ;)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne

Benutzeravatar
Schrompf
Moderator
Beiträge: 3783
Registriert: 26.02.2009, 00:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Fibers und Thread-Pools

Beitrag von Schrompf » 02.03.2016, 18:30

dot hat geschrieben:Puh Ok, wenn du da eine zentrale Datenstruktur mit soviel Contention drauf hast, ist das natürlich generell etwas ungünstig. Nur mal rein prinzipiell: Wenn jemand einen Teil vom Voxelmodell, der gerade gemeshed wird, ändert, sollte der Job, der da grad dran war, nicht sowieso einfach besser abbrechen; weil das halbfertige Mesh is dann sowieso nicht up-to-date? Statt da also Reader/Writer sync zu machen, könnte man einfach lock-free den Job cancellen/restarten...
Zum Einen: da ist nicht viel Contention drauf. Änderungen sind selten, bestenfalls eins zwei mal pro Sekunde.

Und zum Anderen: wie bricht man den Jobs ab? Man könnte höchstens nen bool BitteHoereMalAuf; von außen setzen und müsste dann mit dem Schreibzugriff trotzdem warten, bis alle lesenden Operationen zu Ende gekommen sind. Wir reden hier ja von beliebigem C++-Code - selbst wenn das ein Thread wäre und Du den hart killst, bliebe alles an Ressourcen und Objekten unaufgeräumt. Und den Fiber kannst Du von außen gar nicht killen, weil das ja alles kooperatives Multitasking ist.
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.

Benutzeravatar
Sternmull
Establishment
Beiträge: 264
Registriert: 27.04.2007, 00:30
Echter Name: Til
Wohnort: Dresden

Re: Fibers und Thread-Pools

Beitrag von Sternmull » 02.03.2016, 19:41

Ich war jetzt zu faul alles zu lesen was bisher geschrieben wurde. Aber von den letzten Beiträgen her sieht es so aus als wäre dein Problem eigentlich einfach zu lösen: Nimm SRW Locks. Damit können beliebig viele Threads gleichzeitigen lesenden Zugriff haben und eine seltenen schreib-Zugriffe scheinen ja grundsätzlich nicht das Problem zu sein. Die Lesezugriffe sollten von einem Thread-Pool bearbeitet werden und einzelne Lese-Locks sollten möglichst kurz gehalten werden damit ein Schreibzugriff auch irgendwann mal zum Zuge kommen kann.

odenter
Establishment
Beiträge: 196
Registriert: 26.02.2009, 12:58

Re: Fibers und Thread-Pools

Beitrag von odenter » 04.03.2016, 10:54

Für die Platformunabhängigkeit wäre boost.asio vielleicht das richtige.
Unter Windows werden I/O completion ports verwendet und unter einem Linux wird epoll verwendet wenn mich nicht alles täuscht.
Mehr Infos hier http://think-async.com/Asio/

Ich habe nicht völlig verstanden was Du genau machen willst. Es gibt die Möglichkeit mit boost.asio asynchrone Logic wie synchrone zu behandeln (Stackful/Stackles Coroutines). Willst Du sowas machen?

Antworten