Thread Schlaf-und Windows-Dienste

Arbeite ich an einem Windows-Dienst, der einige Probleme mit Thread.Sleep() so dass ich dachte, ich würde versuchen, einen timer zu verwenden, anstatt, wie diese Frage empfiehlt:

Mit Thread.Sleep() in einem Windows-Dienst

Sache ist, es ist mir nicht ganz klar, wie könnte man dies umsetzen. Ich glaube, das ist der Weg, aber ich wollte nur um sicher zu gehen:

'' Inside The Service Object
Dim closingGate As System.Threading.AutoResetEvent

Protected Overrides Sub OnStart(ByVal args() As String)
   Dim worker As New Threading.Thread(AddressOf Work)
   worker.Start()
End Sub

Protected Sub Work()
   Dim Program = New MyProgram()
   closingGate = New System.Threading.AutoResetEvent(False)
   Program.RunService(closingGate)
End Sub

Protected Overrides Sub OnStop()
   closingGate.Set()
End Sub

'' Inside My Programs Code:
Public Sub RunService(closingGate As AutoResetEvent)
   Dim tmr As New Timer
   '' ...and so on

   closingGate.WaitOne()
End Sub

Abgesehen von VB.Net (Scherz, aber ich würde mit C#, wenn ich könnte.) bin ich auf dem richtigen Weg? Ist das besser als mit Thread.Sleep()?

  • Warum sind die Namen der Variablen aktiviert?
  • Es. Fixiert es.
InformationsquelleAutor Spencer Ruport | 2010-03-08
  1. 19

    Ehrlich gesagt, würde ich sagen, dass ich denke, Sie sind ein wenig abseits der ausgetretenen Pfade hier.

    Erste von allen, der eigentliche code geschrieben, der nicht wirklich Sinn machen; der worker-thread wartet auf ein signal, aber für keinen Grund - es ist wirklich nicht in eine Schleife irgendeiner Art oder auf eine Ressource warten. Zweitens, wenn Sie es ausführen müssen, einige (vielleicht weggelassen) cleanup-code in der Arbeiter nach Erhalt die shutdown-signal, ist Ihr Dienst möglicherweise nicht die worker-thread-genug Zeit, um aufzuräumen.

    Sondern, mehr grundlegend, alles, was Sie getan haben, ist bewegen Sie das problem einen separaten thread. Dies kann halten den service zu reagieren, um den service controller, aber es behebt nicht das problem, und es fügt eine Menge unnötiger Komplexität durch die Verwendung der threads und Mutexe; letztendlich ist es doch nur gehen, um Ihre service schwieriger zu Debuggen, wenn Sie jemals brauchen, um.

    Lassen Sie uns sagen, Sie ausführen müssen einige code alle 5 Sekunden. Die Idee ist, statt "warten" 5 Sekunden, invertieren Sie die Kontrolle, und lass den timer aufrufen, Ihre Arbeit.

    Das ist schlecht:

    protected override void OnStart(string[] args)
{
    while (true)
    {
        RunScheduledTasks();    //This is your "work"
        Thread.Sleep(5000);
    }
}

    Das ist gut:

    public class MyService : ServiceBase
{
    private Timer workTimer;    //System.Threading.Timer

    protected override void OnStart(string[] args)
    {
        workTimer = new Timer(new TimerCallback(DoWork), null, 5000, 5000);
        base.OnStart(args);
    }

    protected override void OnStop()
    {
        workTimer.Dispose();
        base.OnStop();
    }

    private void DoWork(object state)
    {
        RunScheduledTasks();  //Do some work
    }
}

    Das ist es. Das ist alles was Sie tun müssen, um Arbeit zu tun in regelmäßigen Abständen. Solange das Werk selbst nicht läuft, für Sekunden zu einer Zeit, Ihr service bleibt reaktionsschnell Weg zum Dienst-controller. Sie können sogar das anhalten unterstützen, die unter diesem Szenario:

    protected override void OnPause()
{
    workTimer.Change(Timeout.Infinite, Timeout.Infinite);
    base.OnPause();
}

protected override void OnContinue()
{
    workTimer.Change(0, 5000);
    base.OnContinue();
}

    Das einzige mal, wenn Sie brauchen, um zu beginnen, erstellen von worker-threads, die in Ihrem Dienst, wenn Sie die arbeiten selbst ausführen können, für eine sehr lange Zeit, und Sie brauchen die Möglichkeit zum Abbrechen in der Mitte. Das ist eher mit einem guten Angebot design-Aufwand, so dass ich nicht in diese zu bekommen, ohne zu wissen, für sicher, dass es im Zusammenhang zu deinem Szenario.

    Es ist am besten, nicht zu starten, die Einführung von Multithreading-Semantik in Ihren Dienst, wenn Sie es wirklich brauchen. Wenn Sie nur versuchen zu planen, kleine-ish Einheiten der Arbeit zu tun, Sie definitiv nicht brauchen.

    • Aus irgendeinem Grund war ich unter dem Eindruck, dass, wenn ich nicht noch ein thread laufen der service würde kündigen.
    • Ruport: Es ist immer noch ein thread ausgeführt wird, wenn der OnStart - Methode abgeschlossen ist, wie es ist immer noch ein thread ausgeführt wird, wenn OnLoad endet in einer WinForms -Form. Nach ausführen der OnStart code, der service geht in einen message loop, wo es wartet auf Signale von der service controller.
    • Was ist, wenn RunScheduledTasks() nimmt eine unvorhersehbare und potenziell lange Zeit zu laufen? Im Rahmen des oben genannten Beispiel, sagen wir, es kann bis zu 15 Sekunden zu laufen. In diesem Fall wird der timer-Ansatz nicht mehr funktionieren würde, wäre es? Ich meine, die Idee wäre, haben Sie 5 Sekunden zwischen jedem Aufruf RunScheduledTasks(). In diesem Fall ist der Thread.Schlaf Ansatz scheint am besten geeignet für den job, es sei denn, ich bin fehlt etwas?
    • Wenn Sie möchten, dass die Verzögerung zwischen der Ende von der ersten Aufgabe und der Anfang der nächste, dann können Sie den timer, um Feuer nur einmal, und dann zurückgesetzt wird, nachdem die Aufgabe abgeschlossen ist. Dass haben genau das gleiche timing wie die Thread.Sleep Ansatz, aber nicht blockieren den Dienst Steuern. Realistisch betrachtet, wenn das timing ändert sich so drastisch, sollten Sie wahrscheinlich etwas robuster sowieso, also ein job-scheduler und/oder message queue.
    • Wenn das erstellen einer separaten thread auf der OnStart-Methode und Umsetzung aller Logik auf, DerLesen.Schlaf wird nicht blockieren den service. Ich bin nicht sicher, ob ein scheduler arbeiten, aus dem gleichen Grund die ursprüngliche timer-Methode nicht. Der zweite, mit timer feuern nur einmal und zum zurücksetzen nach jeder Beendigung der Aufgabe arbeiten würde, aber ehrlich gesagt finde ich es weniger elegant als der Thread.Schlafen. Gibt es irgendwelche Gründe, warum Thread.Schlaf sollte vermieden werden, für diesen speziellen Fall, außer der service-block?
    • Mit Thread.Sleep ist "elegant" in der gleichen Weise wie Application.DoEvents ist... also ist es ein hack. Was Sie wirklich für die Modellierung ist ein Ereignis, nicht um eine Schleife, und Sie verschwenden ein thread im Prozess. Sie erhalten auch keine Garantien über die tatsächliche timing; Sleep(x) bedeutet eigentlich "Schlaf für mindestens "x" - wenn die anderen threads ausgelastet sind, dann wird es vermutlich viel länger. Können Sie sofort mit diesem in ein kleines service? Sicher, genau wie Sie bekommen können Weg mit viel andere schlechte designs in sehr kleine Projekte. Weiß nur, dass es nicht eine gute Praxis.
    • P. S. die Meisten Planer Griff dieses Szenario einfach nur gut. Quarz verwendet das Konzept von "Fehlzündungen" und die, die ich verwenden können, führen Sie entweder in der Warteschlange oder die letzten-Modus, je nachdem, ob oder nicht, jede Instanz tatsächlich ausgeführt werden muss. Gleichzeitigkeit und Konflikte sind eines der wichtigsten Probleme, die eine scheduling-engine ist bestimmt zu lösen.
    • vielen Dank für Ihre Gedanken, ich bin einverstanden mit dem, was Sie sagen, über-Thread.Schlafen, obwohl ich glaube, Sie sind ein wenig zu kategorisch. Parkplatz, was sich am Ende in einem langen Streit beiseite, was ist der scheduler, die Sie verwenden? Unterstützt Sie in der Warteschlange Ausführung mit einer pause zwischen jedem job? Denn das ist, was ich glaube, die meisten Entwickler, die mit Gewinde Schlafen in einer Schleife erreichen willst.
    • Ich benutze die, die ich schrieb, es doesn T haben einen offiziellen release noch. Was es unterstützt, stabil Startzeiten; zum Beispiel, wenn Sie planen einen job ein, die jede Stunde an der 15-Minuten-Marke, und die Arbeit begann bei 1:15 hört nicht auf, bis 6:00, dann die nächste Veranstaltung bewegt sich entweder in 5:15 oder 6:15, je nach Konfiguration. Die 3. Möglichkeit ist die Warteschlange bis alle vergessene Instanzen bei jeder repräsentiert eine einzigartige Einheit von Arbeit, aber das ist normalerweise nicht der Fall mit der geplanten Arbeitsplätze. Ich persönlich sehe nicht den Punkt der "instabilen mal beginnen, stabile Verzögerung", aber ich werde Zuhören zu Fällen verwenden, wenn Sie Namen einige.
    • Ich habe eine Frage, nachdem der timer eingestellt ist, wie wird dann der timer mehrmals ausgeführt? Ich verstehe das mit der while(true), aber nach onstart führt, ist wie eine Art Schleife?

    InformationsquelleAutor Aaronaught
  2. 1

    Ich schrieb vor kurzem einen service hatte, um einige Arbeit zu tun, dann warte n Minuten, dann Schleife.

    Ich habe auch ein ManualResetEvent (genannt _evt), und ein Aufruf von Set() in OnStop.
    Aber ich brauchte nicht einen timer.

    In der service-thread, die ich hatte:

    for (;;) {

   //do some work
   if (_evt.WaitOne(_waitInterval)) {

       //got the signal => time to leave
       break;
   }
}

    Also, entweder ein timeout aufgetreten ist => Zeit für etwas mehr Arbeit. Oder Set() aufgerufen und die Schleife abgebrochen.

    • Interessant. Wie viel Zeit wird die Arbeit nehmen? Wäre es mal, wenn man Halt in Windows hängen würde, während der code wird immer wieder auf WaitOne(n)?
    • Die Arbeit könnte ein paar Sekunden dauern. Die 1. Sache, die ich in OnStop ist zu sagen, das SCM zu bitte warten Sie 10 Sekunden.
    InformationsquelleAutor Timores
Schreibe einen Kommentar