2016-05-23 5 views
0

Gibt es Race Condition in Situation wie folgt: Wenn ein Thread liest und andere schreibt in separaten Methoden natürlich. Ich bin ein Anfänger zu Multithreading und GleichzeitigkeitEin Thread lesen, andere Thread schreiben auf gemeinsame Variable

class counter { 
int count = 0; 

void increment() { 
    count++; 
} 

int read() { 
    return count; 
} 
} 

class voltest { 
public static void main(String[] args) { 
    final counter c = new counter(); 
    Runnable r1 = new Runnable() { 

     @Override 
     public void run() { 
      // TODO Auto-generated method stub 
      c.increment(); 
     } 
    }; 

    Runnable r2 = new Runnable() { 

     @Override 
     public void run() { 
      // TODO Auto-generated method stub 
      c.read(); 
     } 
    }; 

    Thread t1 = new Thread(r1); 
    Thread t2 = new Thread(r2); 
    t1.start(); 
    t2.start(); 
} 
} 

Antwort

0

Ja, es ist ein Rennen Zustand. Ausdrücke wie count++ sind nicht atomar - sie werden als Lese-Modifiziere-Schreib-Ausdrücke klassifiziert, und ein anderer Thread kann jederzeit auf die Variable zugreifen.

Werfen Sie einen Blick auf this link on Java atomics, die tatsächlich über die Verwendung des Inkrement-Operators spricht.

+0

so wie diese Bedingung zu verhindern? Meine Vermutung ist, dass die Variable vielleicht volatil ist? – cynic123

0

Sie erhalten eine unvorhersehbare Ausgabe in mehreren Durchläufen desselben Programms mit dem aktuellen Code.

Machbar Lösungen:

  1. Wenn nur ein Thread zu schreiben und anderer Thread wird nach Ihrem Code zu lesen, nur flüchtig hinzufügen vor Zählvariable.

  2. Wenn mehrere Threads Daten schreiben und lesen, ändern Sie die Anzahl in AtomicInteger.

  3. Die Schreib- und Lesemethoden werden synchronisiert, was keine gute Lösung ist. AtomicInteger bietet die beste Lösung.

Verwandte SE Frage:

What is the difference between atomic/volatile/synchronized?

+0

Das Hinzufügen von 'volatile' wird die Race-Bedingung nicht beseitigen. Es wird immer noch zwei Threads geben, die auf die Variable zugreifen, das Ergebnis des Programms hängt immer noch davon ab, welcher Thread zuerst auf die Variable zugreift, und es wird immer noch nichts im Programm geben, das den Thread daran hindert, zuerst dorthin zu gelangen. Klassischer Race-Zustand. –

+0

Nur ein Thread ändert die gemeinsame Variable im obigen Fall. –

+1

OK, ich bin schuld daran, etwas anzunehmen: Ich nahm an, das Beispiel sei ein Auszug aus einem Programm, das irgendeine Art von Ausgabe erzeugt, und ich nahm an, dass die Ausgabe davon abhange, ob "increment" vor "read" oder vice aufgerufen wird versa. Es gibt nichts im Programm, das die Reihenfolge steuert, in der diese Methoden aufgerufen werden, also würde es eine Race-Bedingung geben. Aber wenn meine Annahme falsch ist - das Programm produziert tatsächlich keine Ausgabe --- dann gibt es keine Wettlaufbedingung, weil eine Wettlaufbedingung durch das Programm definiert wird, das unterschiedliche Ausgaben erzeugt, abhängig von der Reihenfolge, in der die Fäden laufen. –

Verwandte Themen