Ich arbeite an einem Windows-Dienst, der einige Probleme mit Thread.Sleep() hat, also dachte ich, ich würde stattdessen versuchen, einen Timer zu verwenden, wie diese Frage empfiehlt:
Verwenden von Thread.Sleep () in einem Windows-Dienst
Sache ist mir nicht ganz klar, wie man das umsetzen könnte. Ich glaube, das ist der Weg, aber ich wollte nur sicherstellen:
%Vor% Neben VB.Net (Kidding, aber ich würde C # verwenden, wenn ich könnte.) bin ich hier auf dem richtigen Weg? Ist das besser als mit Thread.Sleep() ?
Ehrlich gesagt, würde ich sagen, dass ich denke, dass Sie hier ein wenig abseits der ausgetretenen Pfade sind.
Zunächst macht der eigentliche Code keinen Sinn. Der Worker-Thread wartet auf ein Signal, aber ohne Grund - er befindet sich nicht in einer Schleife oder wartet auf eine Ressource. Zweitens, wenn Sie nach dem Empfang des Shutdown-Signals einen (möglicherweise weggelassenen) Bereinigungscode im Worker ausführen mussten, kann Ihr Dienst dem Thread möglicherweise nicht genügend Zeit zum Bereinigen geben.
Aber im Grunde ist alles, was Sie getan haben, das Problem in einen separaten Thread zu verschieben. Dies kann dazu führen, dass der Dienst auf den Dienst-Controller reagiert, das Entwurfsproblem jedoch nicht behoben wird - und durch die Verwendung der Threads und Mutexe eine Menge unnötiger Komplexität hinzugefügt wird. Letztendlich wird es Ihren Dienst nur noch schwieriger zu debuggen, wenn Sie es jemals brauchen.
Nehmen wir an, Sie müssen alle 5 Sekunden einen Code ausführen. Die Idee ist, anstatt 5 Sekunden zu warten, invertieren Sie das Steuerelement und lassen Sie den Timer Ihre Arbeit aufrufen.
Das ist schlecht:
%Vor%Das ist gut:
%Vor%Das ist es. Das ist alles, was Sie tun müssen, um in regelmäßigen Abständen zu arbeiten. Solange die Arbeit selbst nicht für mehrere Sekunden ausgeführt wird, bleibt Ihr Dienst gegenüber dem Dienstcontroller reaktiv. Unter diesem Szenario können Sie sogar das Pausieren unterstützen:
%Vor%Der einzige Zeitpunkt, an dem Sie Worker-Threads in Ihrem Service erstellen müssen, ist, wenn die Arbeit selbst sehr lange dauern kann und Sie die Möglichkeit haben, in der Mitte abzubrechen. Das erfordert eine Menge Design-Aufwand, daher werde ich nicht darauf eingehen, ohne sicher zu wissen, dass es mit Ihrem Szenario zusammenhängt.
Es ist am besten, keine Multithread-Semantik in Ihren Service einzuführen, es sei denn, Sie benötigen sie wirklich. Wenn Sie nur versuchen, kleine Arbeitseinheiten zu planen, brauchen Sie es definitiv nicht.
Ich habe kürzlich einen Dienst geschrieben, der etwas arbeiten musste, dann warte n Minuten, dann Schleife.
Ich habe auch ein ManualResetEvent (genannt _evt) und einen Aufruf von Set () in OnStop verwendet. Aber ich brauchte keinen Timer.
Im Service-Thread hatte ich:
%Vor%Entweder ist ein Timeout aufgetreten = & gt; Zeit für etwas mehr Arbeit. Oder Set () wird aufgerufen und die Schleife wird beendet.
Tags und Links .net windows-services multithreading timer sleep