Sleep()/sleep() Probleme
-
Hallo Leute,
ich habe mal wieder ein Problem:
Ich habe eine Main Methode, die ziemlich heftig arbeitet. Und ich habe in tieferen C-Funktionen zwei Threads angestoßen. Jetzt kommt meine Problem.Die Threads in den tieferen Funktionen kommen nicht zum Zug wenn die Mainmethode am ackern ist. Auch nicht wenn ich Main mit Sleep(1000) oder sleep(1000) schlafen lege. Erst wenn die Arbeit abgeschlossen ist, können die anderen Threads wieder an die Arbeit. Und da diese Timeout zu verwalten haben, stellt das ein ziemliches Problem dar.
Es wird das Problem sein, das mit (s/S)lepp(x) immer nur höhere oder gleiche Prioritäten einen Zugriff erhalten. Das Polling in meinen Problem-Threads, muss aber auf jeden Fall erhalten werden. Einfaches erhöhen der Priorität der Threads, ist aber auch keine Option. Von außen anstoßen auch nicht, da es sich um eine Bibliothek handelt. Gibt es andere Methoden? Oder kann man die Main verläßlich, auch wenn der Funktions-Stack noch befüllt ist, schlafen legen?
Gruß Peer
-
Keiner eine Idee? Oder kann mir wenigstens Bestätigen das es an Problemen mit der Priorität liegt?
-
Nein IMHO kann es nicht an den Prios liegen. Wenn Du schläfst müssen die Threads an die Reihe kommen. Die FRAge ist was die gerade tun? Evtl. hast DU EInfach ein Synchronisationsproblem mit Ressourcen. Verwendest Du SendMessage? Wenn ja dann hast Du dort ein Problem.
-
Ja, wir reden mit einem Treiber, und im debugview kann man sehen wie diese alle abgesendet werden. Was für ein Problem kann es den mit dem sendMessage geben?
Ich selber habe den Teil nicht geschrieben, aber ich kann ja mal schauen ob ich da was finde.
-
Wenn Du ein SendMessage auführst an ein Fenster, dass in einem anderen Thread liegt und dieser Thread nicht die MessageLoop ausführt, dann steht SendMessage bis die Nachricht abgeholt wird.
Da Dein MainThread ein Consolen Programm ist vermute ich mal nicht, dass dieses eine Messageloop hat, ansonsten wird diese natürlich durch den Sleep blockiert!
-
Nimmst Du alternativ
PostMessage
-
CodeFinder schrieb:
Nimmst Du alternativ
PostMessageWas unter Umständen nicht geht, wenn die Daten in einem Puffer stehen, der eine begrenzte Lebenszeit hat...
Zudem muss man dann auch beachten, dass die Message Queue für PostMessage in der Größe begrenzt ist...
-
Jops, klar hängt vom Verwendungszweck ab...
-
Danke Leute,
hatte aber dummerweise nix damit zutun.
War eigene Dummheit. Hab für 2 verschiedene Threads nur eine CriticalSection gehabt. Und da ist es kollidiert. Kann man mit einem Debugger aber echt schlecht erkennen.
-
Nightstorm schrieb:
Danke Leute,
hatte aber dummerweise nix damit zutun.
War eigene Dummheit. Hab für 2 verschiedene Threads nur eine CriticalSection gehabt. Und da ist es kollidiert. Kann man mit einem Debugger aber echt schlecht erkennen.Doch kann man. Man kann im Debugger beide Threads anhalten und sehen wo sie stehen!
Zudem! Es ist doch korrekt für beide Threads nur eine Criticalsection zu haben, wenn es darum geht ein und den selben Bereich zu sichern!
Ganz verstehe ich das nicht!
-
1. Nein, ein Thread ist für die Devices, und der zweite für die IO´s
2. geht das auch mit dem Codeblocks? und welchen Befehl muss ich dann nutzen?
-
Nightstorm@home schrieb:
1. Nein, ein Thread ist für die Devices, und der zweite für die IO´s
Sorry aber irgendwie stehe ich auf dem Schlauch. Warum musst Du das in dieser Form gegeneinander sichern.
Nightstorm@home schrieb:
2. geht das auch mit dem Codeblocks? und welchen Befehl muss ich dann nutzen?
Was meinst Du damit "Codeblocks"?
Ich meinte im Debugger einfach "Break all" ausführen. Dann öffnest Du das Threads Fenster und machst überall mal einen Doppelklick! Und siche da anhand des Callstacks kannst Du wunderbar sehen, wer sich hier wie totblockt.
-
Er meint die "Code::Blocks" IDE - hab aber leider keine Ahnung ob die einen Debugger hat bzw. unterstützt der das kann.
-
Man kann den GNU Debugger mit Code::Blocks nutzen; also ja
.
-
@all Danke, für die Hilfe.
@Martin, ich habe für die Devices eine verkette Liste, und für die zu den Devices geschickten IO´s eine verkette Liste. Und die muss man nicht gegenseitig blocken. Ich hab sie aber gegenseitig geblockt, weil ich dummerweise die selbe CriticalSection für beide verwendet habe. Es war programmierer Faulheit.
