Thread.IsInterrupted

So, stelle ich auch mal ne Frage (meine erste?) 😉

(Auch wenn es wahrscheinlich gar keine brauchbare Lösung gibt...)

Gibt es irgendeine Möglichkeit anzufragen ob der aktuelle Thread interrupted wurde (mit thread.Interrupt)? Interrupt feuert ja bei der nächsten Blockierung (ThreadState: WaitSleep.. ) eine Exception, wenn der Thread aber nie blockiert wird merkt er auch nichts davon.

Hintergrund: Mein Thread wird zwar regelmässig blockiert, aber von NT selber - davon merkt die CLR aber nichts und der ThreadState bleibt auf Running - natürlich wird auch keine ThreadInterruptedException geschmissen. Wenn es also möglich wäre zb. jeweils nach dem Zurückkehren einer NT-Blockierung abzufragen ob der Thread interrupted wurde könnte ich mir konstrukte wie Sleep ersparen (um den Thread künstlich in den WaitSleep.. Status zu setzen) ...

Jemand zufällig ne idee?

Habs trotzdem mit

System.Threading.Thread.Sleep(0);

gelöst, funktioniert ganz gut ...

(werde übrigens demnächst einen CodeProject Artikel publizieren zum Thema IPC/SOA mit .NET ... )

Original von cdr
Wenn es also möglich wäre zb. jeweils nach dem Zurückkehren einer NT-Blockierung abzufragen ob der Thread interrupted wurde

Dazu müsste ja erstens überhaupt bekannt sein, dass eine Betriebssystemabhängige Blockierung stattgefunden hat. Wird etwa ein Event dazu ausgelöst? Bis jetzt habe ich unter .NET zwar noch nicht mit Threads gearbeitet. Es erscheint mir aber doch sehr ungewöhnlich!

Wie wäre es denn mit einem Sleep(0)? Das sollte nicht allzusehr aufhalten und ich bin es von anderen Entwicklungsumgebungen gewohnt, dass auch bei einem Sleep(0) der Scheduler prüft, ob eine weiterer Thread an die Reihe kommen soll.

-Jürgen

thnx für die antwort

Original von GhoBu
Dazu müsste ja erstens überhaupt bekannt sein, dass eine Betriebssystemabhängige Blockierung stattgefunden hat. Wird etwa ein Event dazu ausgelöst? Bis jetzt habe ich unter .NET zwar noch nicht mit Threads gearbeitet. Es erscheint mir aber doch sehr ungewöhnlich!

Nachdem die blockierung (WinAPI WaitForSingleObject Syscall) aufgelöst wird wird ganz normal der nächste Befehl ausgeführt. Threads sind ja linear.
Habe es tatsächlich mit Sleep(0) gelöst (die Sleep Methode feuert dann wie erwartet ThreadInterruptedException), siehe oben (bin dir kurz zuvorgekommen..) ... funtkioniert bestens.