Seite 2 von 2

Re: Fibers und Thread-Pools

Verfasst: 02.03.2016, 16:41
von Krishty
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 ;)

Re: Fibers und Thread-Pools

Verfasst: 02.03.2016, 17:30
von Schrompf
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.

Re: Fibers und Thread-Pools

Verfasst: 02.03.2016, 18:41
von Sternmull
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.

Re: Fibers und Thread-Pools

Verfasst: 04.03.2016, 09:54
von odenter
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?