C Threads - Threadpool - Threads zurücksetzten - Threads schlafen legen - pthreads

[hell-student]

Hallo Zusammen,

ich hänge immer noch an einer wichtigen Implementierung und frage mich gerade wie es möglich ist unter C pthreads zurückzusetzen. Einfaches Szenario:

1. Server startet Threadpool mit z.b 20 Threads
2. Client macht eine Anfrage -> Server weckt einen Thread aus dem Pool aus und gibt ihm die Aufgabe
3. Client macht neue Anfrage (vorherige Bearbeitung auf Serverseite ist noch nicht beendet) -> Server resetet den aktuell laufenden Thread für Client und startet die Bearbeitung mit
a) diesem Thread oder
b) neu gewecketen Thread
von neuen

Dies ist deshalb von nöten, da die vorherige Berechung nicht mehr auf aktuellen Daten arbeitet und somit verworfen werden soll.

Ich könnte den Thread auf Serverseite auch beenden, müsste dann einen neuen starten und das kostet einfach Performance. Gibt es schon eine Implementierung von einem solchen Feature, oder wie könnte ich es umsetzten?
thx

 

[mrhanky01]

Semaphoren sind die Lösung mit denen kannst du steuern welcher Thread wo ist , sie warten lassen schlafen legen und sogar töten.

Einfach mal googlen nach Semaphoren

hier 2 1/2 sekunden gegoogelt

http:// softpixel.com/~cwright/programming/threads/threads.c.php

 

[hell-student]

Semaphoren bringen mir hier doch nichts. Ich habe wohl nicht genau erklärt, was mein Problem ist.

Ich würde gerne einen Thread, der gerade etwas Berechnet (also eine Arbeit verrichtet) zurück in den Threadpool schicken, also von seiner Arbeit entbinden, egal wie weit er gerade war, also quasi resetten in den Urzustand.

 

[GrinderFX]

Was nun?
Willst du den Thread nun beenden oder unterbrechen?
Das sind 2 unterschiedliche Dinge.

 

[hell-student]

Was nun?
Willst du den Thread nun beenden oder unterbrechen?
Das sind 2 unterschiedliche Dinge.

Ich möchte ihn nicht beenden, da ich ja dadurch wieder einen neuen Thread erzeugen muss, was ja nicht der Sinn eines Threadpools ist. Ich möchten ihn quasi resetten.

Ich möchte ihn Unterbrechen und zum Threadpool zurücklegen, er soll also auf eine neue Aufgabe warten

 

[GrinderFX]

Da ein Thread in der Regel als Funktions aufgerufen wird und dieser nur zur Erzeugung Parameter entgegen nehmen kann, wirst du wohl tatsächlich nicht um Semaphore drumrum kommen. Denn irgendwie musst du ja die Nachrichtenvariablen oder was auch immer, vor parallelem Zugriff schützen.

 

[Tigerass 2.0]

Wenn es nicht Threadsafe sein muss kann es ja auch soetwas in der Art sein:
extern bool reset;
Ist zwar böse, aber was solls. Das kostet dich wahrscheinlich weniger Performance als eine Windows-API-Funktion, welche meines erachtens nach nicht existiert. Lediglich idle/resume Thread sind mir bekannt. Restart oä nicht. Und für dein Problem wurden ja deshalb auch Semaphores, und schneller noch die Interlocked Funktionen geschrieben, wie z.B. InterlockedExchange. (sehr hardwarenah)

LG Tigerass

 

[Freezedevil]

Ich versteh nicht was er mit Semaphoren soll. Entweder versteh ich sein Anliegen nicht richtig oder ihr.

Du könntest mal in Richtung setjmp/longjmp googlen. Ich kann dazu leider nicht viel sagen, da ich davon auch letzte Woche erst was gehört hab, aber ich könnte mir gut vorstellen, dass das mit Threads nicht so gesund ist.

 

[Tigerass 2.0]

setjmp/longjmp ist komplizierter, funktioniert auch, man muss aber immernoch das Signal bekommen, wenn der longjmp ausgeführt werden soll. Da kommen dann Semaphores und die Interlocked-Funktionen wieder ins Spiel, wenn es threadsafe sein soll.

setjmp/longjmp ist auch zum Resetten von komplexen Programmen gedacht, kann aber halt schnell unübersichtlich werden. Ist wie mit goto

LG Tigerass

 

[Dese]

was macht ihr das so kompliziert?
also ich weiß ja nicht ob es dafür eine extra api in windows oder so gibt. aber selbst gebacken geht das recht fix:

bau dir ne erweiterte thread-klasse mit einer speziellen methode, z.b. partRun(...)
in der eigentlichen run hast du ne logik drinn, die in etwa wie folgt aussieht:

-solange thread leben soll
  - solange es nichts zu tuen gibt
      sleep(100) // oder alternativ nutze die thread methode wait um dich schlafen zu legen bis ein anderer notify für diesen thread aufruft

  - solange es was zu tuen gibt dann
    - partRun()

die idee ist, dass du dem thread eine aufgabe gibst. wenn er keine hat, dann legt er sich schlafen. wenn er eine hat führt er diese aus und schaut periodisch nach, ob er immer noch weiter arbeiten soll oder nicht.

natürlich gibt es jeh nach api noch elegantere möglichkeiten. das ist lediglich ein einfacher ansatz so etwas selbst zu basteln.

 

[hell-student]

Danke für die Antworten.

Das ganze wird unter Linux auf einem FPGA Board laufen, worauf ein Core ist, der mit 70 Mhz läuft. Daher brauche ich dringend die Funktionalität einen Thread die Arbeit zu entziehen und ihn zum Threadpool zurückzuschicken. Den Thread zu löschen und einen neuen zu erzeugen kostet zuviel Zeit. Register müssen gesichert werden, ...

 

[command1989]

Hi,

ich würde mal sagen der Vorschlag von Dese macht Sinn wenn in dem Thread eine Schleife durchgeführt wird und man auch nach einem oder n Schleifendurchgängen schaut ob der Thread noch laufen soll. Prüft er dies erst nachdem er die kompletten Daten abgearbeitet sind, dann kann es ja sein, dass er eigentlich beendet wurde und Prozessorzeit verheizt hat (das ist natürlich abhängig von der Problemgröße mehr oder minder schlimm)

 

[antred]

Ich glaube nicht, daß die vom OP geforderte Funktionalität überhaupt möglich ist. Wenn ich es richtig verstanden habe, möchte der OP einem Thread, der gerade irgend welchen Code abarbeitet, von außen her quasi sofort dazu veranlassen, das weitere Bearbeiten dieses Codeteils abzubrechen und dann in einem völlig anderen Kontext weiterzulaufen (nur daß dieser andere Kontext eben nichts weiter macht, als den Thread bis auf weiteres in den Schlummerzustand zu versetzen, aus dem er nach Bedarf später geweckt werden kann, so daß der Thread dann mit einer anderen Aufgabe weiterarbeiten kann).

Einzige Option scheint mir in der Tat die von Dese vorgeschlagene Variante zu sein, einen Mechanismus zu erstellen, der eine Aufgabe in mehrere Unterteile auspaltet und den kompletten Zustand der aktuell zu bearbeitenden Aufgabe in einer geeigneten Struktur abspeichert. Dann muß der Thread nach jedem Teilschritt per condition variable überprüfen, ob die weitere Bearbeitung der Aufgabe noch gewünscht ist und eventuell abbrechen. Das geht also nur kooperativ, also der Thread muß selbst entscheiden. Du kannst meines Wissens einem anderen Thread nicht von außen her dazu zwingen, in einen anderen Kontext zu wechseln (wie es z.B. ein Thread mit sich selbst über setcontext() könnte).