Asynchrone Ping

Haben Sie keine Verriegelung an allen? Das sieht aus wie dein problem zu mir. Ich kann sehen, alle Arten von race-conditions und Speicher Prozessor-cache-Probleme potenziell in Ihrem code.

Versuchen Sie es mit lock für den Schutz der recievedIpAddresses == sentPings und

sentPings++;
//This counts pings being sent out
pingCounter++;

Mit lock

Zum Beispiel:

private readonly object SyncRoot = new object();

public void MainMethod()
{
    foreach (string str in ListContainingAddresses)
    { ... }
    lock (SyncRoot) { sentPings++; }
    ....
}

public void pingCompleted(object sender, PingCompletedEventArgs e)
{
    //This counts recieved addresses 
    lock (SyncRoot) { recievedIpAddresses++; } //lock this if it is used on other threads

    if (e.Reply.Status == IPStatus.Success)
    {
        //Do something
    }
    else
    {
        /*Computer is down*/
    }
    lock (SyncRoot) { //lock this to ensure reading the right value of sentPings
        //This checks if sent equals recieved
        if (recievedIpAddresses == sentPings )
        {
            //All returned
        }
    }
}

Dem obigen Beispiel wird die Kraft, die liest und schreibt von shared-memory, so dass verschiedene CPU-Kerne nicht Lesen unterschiedliche Werte haben. Allerdings, je nach code, den Sie vielleicht brauchen viel mehr coarse-grained locking, wo die erste Schleife schützt sowohl sentPings und pingCounter in einem lock, und vielleicht sogar die zweite Methode ist komplett geschützt mit einem lock.

Können die Leute sagen, nicht zu verwenden lock denn es verursacht performance-Probleme und lock-free ist sehr trendy. Die bottom line ist lock ist einfacher als andere alternativen die meisten der Zeit. Möglicherweise müssen Sie Ihre sperren mehr grobkörnige, als das obige Beispiel, weil Sie potenziell race-Bedingungen als auch. Es ist schwer zu geben, eine bessere Probe, ohne zu sehen, das gesamte Programm.

Interlocked.Increment

Hauptgrund für den Einsatz lock hier ist die Kraft, die jeder Lesen und schreiben kommen aus dem Arbeitsspeicher, nicht die CPU-cache, und daher sollten Sie konsistente Werte. Eine alternative zum sperren ist die Verwendung Verriegelt.Inkrement, aber wenn Sie diese auf zwei separate Variablen müssen Sie sorgfältig beobachten, für race conditions.

Race conditions

(Edit)

Selbst wenn Sie sperren Sie möglicherweise ein problem haben. Sehen Sie diese Zeitleiste für 13-Ziel-Adressen (Pech für einige). Wenn Sie sich nicht wohl mit, warum das so ist, dann haben Sie einen Blick auf "Verwaltete Threading-Grundlagen" und "Threading in C# - Joseph Albahari"

• T1: 1 mal
  • T1: Ping gesendet
  • T1: sentPings++
• T2: 1 mal
  • recievedIpAddresses++;
  • T2: andere Sachen
• inzwischen T1: 12 mal
  • T1: Ping gesendet
  • T1: sentPings++ (jetzt gleich 13)
• T2: recievedIpAddresses == sentPings test jetzt ausfällt, sind Sie nicht gleich
• T3 durch zu T14: Eintritt pingCompleted und hat recievedIpAddresses++;
• T1 abgeschlossen ist, die Anwendung wird auf das schreiben der ping zählt (oder schlimmer noch beendet ganz), bevor die anderen 12 threads wieder in den hintergrund

Müssen Sie sorgfältig beobachten, für diese Art von race-Bedingung in den code ein, und passen Sie es entsprechend. Das ganze über threads ist, dass Sie sich überlappen Ihre Operationen.

SyncRoot

Fußnote:

Warum ist SyncRoot erklärt: private readonly object SyncRoot = new object();?

• Es ist eine Klasse Feld zu schützen, class-Felder, wenn Sie eine static console-app, es muss sein static. Aber, wenn Sie static in eine Klasse, dann ist jede Instanz wird die Sperre auf das gleiche Objekt, so wird es Konflikte
• Es ist readonly zu erklären, die Absicht, und verhindern, dass Sie (oder andere Teammitglieder) überschreiben, die es später
• Es ist ein object als:
  • Sie brauchen nicht alles andere als ein Objekt
  • können Sie nicht sperren, die auf eine Wert-Typ
  • sollte man nicht sperren Sie Ihre Instanz der Klasse (um zu verhindern, dass deadlocks in komplizierter code)
  • sollte man nicht öffentlich machen (auch um zu verhindern, dass deadlocks)
• Es instanziiert wird, zusammen mit der Klasse (in eine thread-sichere Weise) durch diese Aussage
• Heißt es SyncRoot als ein Beispiel; Visual Studio hat in der Vergangenheit nannte es in seiner snippets