Threading
-
SWW13 schrieb:
Man Problem ist bloß das ich mich mit Threads nicht sonderlich auskenne. Wenn irgend jemand einen groben Ansatz schreiben könnte und erklären wie ich mit den Threads umgehen kann wäre ich sehr froh.
Ansatz: Lern es richtig, sonst gibts nur Müll.
-
Ich hab das ganze ein wenig überarbeitet, scheint auch einigermaßen gut zu funktionieren.
Jetzt stell ich mir bloß die Frage ob das von der Performance her mit Threads sinnvoll ist oder ob jemand besser Vorschläge hat.
Und was mir noch eingefallen ist, der TestThread ist nur ein Bsp. ich habe auch andere Funktionen/Threads die nicht immer das gleiche durchlaufen. (Bsp. TestThread 2)
void startThreads() { for(int i = 0; i < ThreadNum; i++) { ThreadRunning = true; //<-bool ResumeThread(Threads[i]); while(ThreadRunning)//<-Der Thread setzt sie auf false bevor er sich slebst pausiert Sleep(0); } } void TestThread() { while(1) { //Tu Was //[...] ThreadFinished(); //<-Setzt ThreadRunning auf false SuspendThread(GetCurrentThread()); } } void TestThread2() { while(Eingabe Namen) { Gedrückte Buchstaben zum Namen hinzufügen(); ThreadFinished(); SuspendThread(GetCurrentThread()); } Begrüße Spieler(); }
-
Von CreateThread rate ich im Vorfeld schonmal ab.
Warum?
-
FraggEsel schrieb:
Von CreateThread rate ich im Vorfeld schonmal ab.
Warum?
MSDN schrieb:
A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and _endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multi-threaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions.
-
FraggEsel schrieb:
Von CreateThread rate ich im Vorfeld schonmal ab.
Warum?
Sieh dir doch einfach den Link an, den ich gepostet hab.
-
SWW13 schrieb:
Also, um das ganze mal etwas konkreter und verständlicher zu erläutern:
Das ganze ist Teil eines Spiels, das ich bisher in lite-C (eine recht einfache Programmiersprache für Anfänger) geschrieben hatte und jetzt über das enthaltene SDK in C++ umschreibe. Einziger Hacken, in lite-C gibt es eine Funktion wait(Anzahl der Frames) die es so nicht im SDK nicht gibt.
Wozu ist diese Funktion denn gut? Hört sich für mich jetzt nicht nach einem Grund an multi-threading zu verwenden, sondern eher so als ob du eine Sleep-Funktion in einem Thread wolltest.
-
Wie jetzt? schrieb:
Wozu ist diese Funktion denn gut? Hört sich für mich jetzt nicht nach einem Grund an multi-threading zu verwenden, sondern eher so als ob du eine Sleep-Funktion in einem Thread wolltest.
Eigentlich schon, bloß das die "Sleep-Funktion" auf das beenden einer Funktion warten soll die im Main-Thread gestartet wurde. Und diese Funktion sollte nachher in mehreren Threads gleichzeitig verwendet werden können und zwar so, dass alle bis zu ihrer "Sleep-Funktion" ausgeführt werden und dann darauf warten dass das nächste Frame gerendert wird bzw. die Render Funktion beendet ist.
Wenn es eine solche Funktion gibt wäre das natürlich deutlich einfacher, ich hab bloß nichts in der Richtung gefunden.
-
Ich denke, es wäre ratsam, dein Design mal grundsätzlich zu überdenken. Threads sind dafür da, gleichzeitig Berechnungen durchzuführen. Nicht dafür, aufeinander zu warten und im Grunde einen sequentiellen Ablauf abzubilden. Denn so hört sich das irgendwie an...
-
_matze schrieb:
Ich denke, es wäre ratsam, dein Design mal grundsätzlich zu überdenken. Threads sind dafür da, gleichzeitig Berechnungen durchzuführen. Nicht dafür, aufeinander zu warten und im Grunde einen sequentiellen Ablauf abzubilden. Denn so hört sich das irgendwie an...
Stimmt soweit, ich will Funktion oder Teile einer Funktion sequentiell durchlaufen. Letzteres macht mir allerdings Probleme weil es meines Wissens keine Funtkion JumpToLine x in Funktion y gibt.
Deswegen bin ich auf die Idee mit den Threads gekommen, sie werden ja im Grunde auch nur nach einander Abgearbeitet.
Am einfachsten wäre es ja, wenn alle Funktionen und Teile von Funktionen in einer Liste stehen würden und man dann immer an die Stellen springt wo die Funktion oder ein Teil von ihr anfängt und dann diese bis zu Punkt x abläuft und dann zur nächsten (Teil-)Funktion springt und das bis zur letzten und dann zur Main-Funktion zurückkehrt.
-
Dann splitte deine Funktionen doch einfach, so dass du von jeder Funktion aus diese benötigten Teile aufrufen kannst.
Aber so wie du das schreibst hört sich das schon sehr nach einem Designfehler an.
P.S. Es ist tatsächlich möglich in einem Programm solche Sprünge durchzuführen, aber in deinem eigenen Interesse sage ich dir nicht wie, sonst machst du das nachher noch und das wird noch unschöner als deine Thread-Sleep-Halb-Sequentiell-Methode :p
-
SWW13 schrieb:
void main() //<------------------------- { while(Neues Frame()) { Alle Threads bis zum nächsten wait ausführen(); } }void main

http://www.c-plusplus.net/forum/viewtopic-var-p-is-284489.html
-
FreakY<3Cpp schrieb:
void main

Upps, da hab ich beim schreiben geschlafen, war auch nur nen Psyeudo Code um zu zeigen wie ich mir das vorgestellt habe. Meine richtig Main hat natürlich einen Integer als Rückgabewert.
Das mit dem dem Desingfehler stell ich langsam selber fest, die Funktionen zu unterteilen sollte sinnvoller sein als meine bisherige Planung. Ich werde jetzt mal das gesammte Projekt neu plannen und zwar mit der Tatsache das Funktionen nicht länger als Frame ausgeführt werden können.
@Tippgeber: Könntest du mir trotzdem mal sagen wie das funktioniert, ich kann es einfach nicht lassen alles mögliche zu testen. Dadurch hab ich schließlich auch programmieren gelernt, aber recht hast du, sinnvoll ist es in dem Projekt nicht.
-
SWW13 schrieb:
@Tippgeber: Könntest du mir trotzdem mal sagen wie das funktioniert, ich kann es einfach nicht lassen alles mögliche zu testen. Dadurch hab ich schließlich auch programmieren gelernt, aber recht hast du, sinnvoll ist es in dem Projekt nicht.
Such mal nach longjmp.
-
Tippgeber schrieb:
Such mal nach longjmp.
Lass das!

-
Zu spät xD. Wenn ich das richtig verstanden hab speichert die Funktion den Zustand und stellt ihn später wieder her, was ziemlich auf die Performance gehen müsste. Ich werde es ja auch nicht (zumindest nicht bei dem Projekt) verwenden.
Auch wenn ihr mir jetzt nicht direkt geholfen habt, danke dass ihr mich auf den richtigen Weg gebracht hab.
-
SWW13 schrieb:
Zu spät xD. Wenn ich das richtig verstanden hab speichert die Funktion den Zustand und stellt ihn später wieder her, was ziemlich auf die Performance gehen müsste. Ich werde es ja auch nicht (zumindest nicht bei dem Projekt) verwenden.
Auch wenn ihr mir jetzt nicht direkt geholfen habt, danke dass ihr mich auf den richtigen Weg gebracht hab.
Das Teil gibt es in C++ wohl nur, weil es in C vorhanden war/ist. Wobei ich mich bis heute frage wozu man das in C hat. Ich meine mal gelesen zu haben, dass ein bestimmter C++ Compiler das für die Implementierung des Exception-Handlings verwendet.
Wenn mir jemand ein Beispiel liefern kann wo longjmp wirklich notwendig ist, dann immer her damit.
-
Tippgeber schrieb:
Wenn mir jemand ein Beispiel liefern kann wo longjmp wirklich notwendig ist, dann immer her damit.
Ist std::string wirklich notwendig?
Wirklich notwendig ist garnichts. Aber sjlj(setjump/longjump)-exceptions sind durchaus verbreitet. generell bietet sjlj eben einen mechanismus der anders nicht realisierbar ist. fuer fehlerbehandlung recht praktisch.
notwendig ist aber garnichts.