Speicher Barrieren und coding-Stil über eine Java-VM

Angenommen ich habe eine statische komplexe Objekt wird in regelmäßigen Abständen aktualisiert, die durch einen pool von threads, und Lesen Sie mehr oder weniger ständig in eine lang andauernde-thread. Das Objekt selbst ist immer unveränderlich und spiegelt den neuesten Stand von etwas.

class Foo() { int a, b; }
static Foo theFoo;
void updateFoo(int newA, int newB) {
  f = new Foo();
  f.a = newA;
  f.b = newB;
  //HERE
  theFoo = f;
}
void readFoo() {
  Foo f = theFoo;
  //use f...
}

Kümmert mich nicht im geringsten, ob mein reader sieht das alte oder das neue Foo, aber ich brauche, um zu sehen, ein vollständig initialisiertes Objekt. IIUC, Die Java-Spezifikation besagt, dass ohne eine memory barrier HIER, ich kann sehen, ein Objekt mit f.b initialisiert, aber f.eine noch nicht im Gedächtnis. Mein Programm ist ein real-world-Programm, das wird früher oder später Begehen Sachen zu Speicher, damit ich nicht brauchen, um tatsächlich zu Begehen, der neue Wert von theFoo Speicher sofort (obwohl es würde nicht Schaden).

Was denken Sie, ist die lesbare Art und Weise zu implementieren, die memory-Barriere ? Ich bin bereit zu zahlen ein wenig Leistung Preis der Lesbarkeit zuliebe, wenn es sein muss. Ich denke, ich kann nur synchronisieren Sie die Zuordnung auf " Foo " und " das funktionieren würde, aber ich bin nicht sicher, es ist sehr offensichtlich, jemand liest den code, warum ich das tun. Ich konnte auch synchronisieren Sie die gesamte Initialisierung des neuen Foo, aber das würde die Einführung von mehr sperren, die tatsächlich benötigt werden.

Wie würden Sie es schreiben so, dass es so lesbar wie möglich ?

Bonus-kudos für ein Scala-version 🙂

  • Aus dem Gedächtnis, ich glaube nicht, dass Sie Lesen die Java-spec richtig. Könnten Sie verweisen auf den Abschnitt, wo Sie denken, es sagt, dass.
  • java.sun.com/docs/books/jls/second_edition/html/memory.doc.html und speziell "17.11: Out of order schreibt" verdeutlicht dies (die Regeln selbst sind auf der gleichen Seite am 17.2 und 17.3). Ich kann Lesen, falsch aber.
  • Bär: ich glaube, @Jean ist richtig in seiner Einschätzung hier... siehe meine Antwort und schieben Sie Sie zurück, wenn ich habe es falsch verstanden. Lesen Sie die JMM Besonderheiten jeden Fall erinnert eine Wurst gemacht!
  • Ich Stimme mit Ihr (und Jean) Bewertung und abgestimmt haben, für Ihre Antwort.
  • gute Bearbeitungen zu Ihrer Frage. Ich habe versucht zu Adresse Lesbarkeit, aber wie alles andere Parallelität Verwandte, die Dokumentation im code ist der beste Weg, um es lesbar. Sie können auch die JCiP Parallelität Anmerkungen zu Programmatischer Sachen Dokument (D. H., @Immutable, @ProtectedBy, etc...): javaconcurrencyinpractice.com/annotations/doc/index.html
  • Ich denke, so. final und volatile klingen wie gute und klare technische Lösungen; der rest der Lesbarkeit wird kommen aus eine gute Dokumentation. Vielen Dank für den Hinweis auf JCiP Parallelität Anmerkungen: Sie wird in der Tat die Lesbarkeit zu verbessern.

InformationsquelleAutor Jean | 2010-10-18
  1. 45

    Kurze Antworten auf die Ursprüngliche Frage

    • Wenn Foo ist unveränderlich, machen einfach die Felder Finale wird eine komplette Initialisierung und beständige Sichtbarkeit der Felder für alle threads unabhängig der Synchronisation.
    • Ob oder nicht Foo ist unveränderlich, Veröffentlichung über volatile theFoo oder AtomicReference<Foo> theFoo ausreichend ist, um sicherzustellen, dass Schreibvorgänge in die Felder sind sichtbar für alle Threads Lesen über theFoo Referenz
    • Mit einem einfachen Zuordnung zu theFoo -, reader-threads sind nie garantiert keine update -
    • Meiner Meinung nach, und basierend auf JCiP, die "besten lesbaren Art und Weise zu implementieren, die memory-Barriere" ist AtomicReference<Foo> mit expliziter Synchronisation kommen in der zweiten, und die Verwendung von volatile kommen im Dritten
    • Leider habe ich nichts zu bieten im Scala

    Können Sie volatile

    Schuld ich Ihnen. Jetzt ich bin süchtig, ich habe ausgebrochen JCiP, und jetzt Frage ich mich, ob jeder code, den ich jemals geschrieben habe, ist korrekt. Der code-Ausschnitt ist in der Tat potentiell inkonsistent. (Edit: siehe weiter unten den Abschnitt über die Sichere Veröffentlichung über volatilen.) Den thread Lesen konnte auch sehen abgestanden (in diesem Fall, was auch immer die default-Werte für a und b waren) für unbegrenzte Zeit. können Sie eine der folgenden Optionen, um die Einführung eines passiert-bevor edge:

    • Veröffentlichen über volatile werden, wodurch eine happens-before-edge-äquivalent zu einem monitorenter (Seite Lesen) oder monitorexit (schreiben-Seite)
    • Verwenden final Felder ein und initialisieren Sie die Werte im Konstruktor vor der Veröffentlichung
    • Einführung einer synchronized-block beim schreiben der neuen Werte zu theFoo Objekt
    • Verwenden AtomicInteger Felder

    Diese bekommt die schreibreihenfolge gelöst (und löst Ihre Probleme bei der Anzeige). Dann müssen Sie die Sichtbarkeit der Adresse des neuen theFoo Referenz. Hier volatile geeignet ist -- JCiP sagt in Abschnitt 3.1.4 "Volatile-Variablen" (und hier ist die variable ist theFoo):

    Sie können flüchtige Variablen nur, wenn alle folgenden Kriterien erfüllt sind:

    • Schreibt die variable nicht abhängig von seinem aktuellen Wert, oder Sie können sicherstellen, dass nur ein einzelner thread immer aktualisiert den Wert;
    • Die variable nicht an Invarianten mit anderen Variablen, und
    • Verriegelung ist nicht erforderlich, für jeden anderen Grund, während der variable, auf die zugegriffen wird

    Ist, wenn Sie die folgenden, Sie sind golden:

    class Foo { 
  //it turns out these fields may not be final, with the volatile publish, 
  //the values will be seen under the new JMM
  final int a, b; 
  Foo(final int a; final int b) 
  { this.a = a; this.b=b; }
}

//without volatile here, separate threads A' calling readFoo()
//may never see the new theFoo value, written by thread A 
static volatile Foo theFoo;
void updateFoo(int newA, int newB) {
  f = new Foo(newA,newB);
  theFoo = f;
}
void readFoo() {
  final Foo f = theFoo;
  //use f...
}

    Einfach und Lesbar

    Mehrere Leute auf diesem und anderen threads (Dank @Johannes V) beachten Sie, dass die Behörden auf diese Fragen unterstreichen die Bedeutung der Dokumentation von Synchronisation und Annahmen. JCiP Gespräch im detail über dieses, bietet eine Satz von Anmerkungen, die verwendet werden können, für die Dokumentation und statische überprüfung, und Sie können auch einen Blick auf die JMM Kochbuch für Indikatoren zu bestimmten Verhaltensweisen, die erfordern würde, Dokumentation und links zu den entsprechenden Referenzen. Doug Lea hat sich auch bereit eine Liste der Probleme zu berücksichtigen, wenn dokumentieren Parallelität Verhalten. Die Dokumentation ist angemessen, insbesondere wegen der Besorgnis, Skepsis und Verwirrung um concurrency-Probleme (SO: "Java concurrency Zynismus zu weit gegangen?"). Auch tools wie FindBugs sind jetzt eine statische überprüfung der Regeln, zu beachten, Verstöße gegen JCiP annotation der Semantik, wie "Inkonsistente Synchronisierung: IS_FIELD-NOT_GUARDED".

    Bis Sie denken, Sie haben einen Grund etwas anderes zu tun, es ist wahrscheinlich am besten zu gehen mit den meisten lesbare Lösung, so etwas wie dies (danke, @Burleigh Bär), mit dem @Immutable und @GuardedBy Anmerkungen.

    @Immutable
class Foo { 
  final int a, b; 
  Foo(final int a; final int b) { this.a = a; this.b=b; }
}

static final Object FooSync theFooSync = new Object();

@GuardedBy("theFooSync");
static Foo theFoo;

void updateFoo(final int newA, final int newB) {
  f = new Foo(newA,newB);
  synchronized (theFooSync) {theFoo = f;}
}
void readFoo() {
  final Foo f;
  synchronized(theFooSync){f = theFoo;}
  //use f...
}

    oder, möglicherweise, da es sauberer ist:

    static AtomicReference<Foo> theFoo;

void updateFoo(final int newA, final int newB) {
  theFoo.set(new Foo(newA,newB)); }
void readFoo() { Foo f = theFoo.get(); ... }

    Wann ist es angebracht zu verwenden volatile

    Beachten Sie zunächst, dass diese Frage bezieht sich auf die Frage hier, aber angesprochen wurde viele, viele Male auf SO:

    In der Tat, eine google-Suche: "site:stackoverflow.com +java +flüchtigen +Schlüsselwort" gibt 355 deutliche Ergebnisse. Verwendung von volatile ist am besten, eine flüchtige Entscheidung. Wann ist es sinnvoll? Die JCiP gibt einige abstrakte Orientierung (oben zitiert). Ich werde sammeln einige weitere praktische Richtlinien hier:

  2. Ich mag diese Antwort: "volatile können verwendet werden, um sicher zu veröffentlichen unveränderliche Objekte", die ordentlich kapselt die meisten der Bereich könnte man erwarten, von einem Anwendungsprogrammierer.
  3. @mdma ist Antwort hier: "volatile ist sehr nützlich in der lock-freie algorithmen", fasst eine andere Klasse von Anwendungen—Besondere Zwecke, lock-freie algorithmen, die ausreichend Leistung sensible verdient eine sorgfältige Analyse und überprüfung durch einen Sachverständigen.

    4. Sichere Veröffentlichung über flüchtige

    Folgenden bis auf @Jed Wesley-Smith, es scheint, dass volatile bietet nun stärkere Garantien (seit JSR-133), und die frühere Behauptung", die Sie verwenden können volatile sofern das Objekt veröffentlicht ist unveränderlich" ist ausreichend, aber vielleicht nicht notwendig.

    Blick auf die JMM FAQ, die beiden Einträge Wie final Bereichen arbeiten unter den neuen JMM? und Was bedeutet volatile machen? nicht wirklich befasst mit zusammen, aber ich denke, dass die zweite gibt uns, was wir brauchen:

    Der Unterschied ist, dass es jetzt kein
    mehr so leicht neu zu ordnen normalen Bereich
    Zugriffe um Sie herum. Schreiben
    volatile-Feld hat den gleichen Speicher
    Wirkung wie bei einem monitor release, und
    Lesen aus einer flüchtigen Feld hat die
    gleiche memory-Effekt, wie ein monitor
    erwerben. In Effekt, da das neue
    memory-Modell stellen strengere
    Einschränkungen für die Neuordnung des flüchtigen
    Feld-Zugriffe mit anderen Feld
    Zugriffe, flüchtige oder nicht, nichts
    das war sichtbar zu thread A, wenn es
    schreibt flüchtigen Feld f wird
    sichtbar, thread B, wenn es liest f.

    Ich werde beachten Sie, dass trotz mehrerer rereadings von JCiP, den entsprechenden text dort nicht springen heraus auf mich, bis Jed hingewiesen. Es ist auf p. 38, Abschnitt 3.1.4, und es sagt mehr oder weniger das gleiche wie das vorhergehende Zitat-das veröffentlichte Objekt müssen nur effektiv unveränderlich, keine final erforderlichen Felder ein, QED.

    Älteren Sachen, gehalten für die Rechenschaftslegung

    Einen Kommentar: irgendeinen Grund, warum newA und newB können nicht als Argumente an den Konstruktor? Dann verlassen Sie sich auf die Veröffentlichung von Regeln für Konstruktoren...

    Auch, mit einem AtomicReference wahrscheinlich klärt Unsicherheiten (und vielleicht kaufen Sie auch andere Vorteile, je nachdem, was Sie brauchen, zu tun bekommen in den der rest der Klasse...) Auch jemand schlauer als ich kann Ihnen sagen, wenn volatile würde dieses Problem lösen, aber es scheint immer kryptisch für mich...

    In der weiteren rezension, ich glaube, dass der Kommentar von @Burleigh Bär oben ist korrekt --- (EDIT: siehe unten), , die Sie eigentlich nicht haben, um sorgen über die out-of-sequence-Bestellung hier, da veröffentlichen Sie ein neues Objekt theFoo. Während ein anderer thread wäre denkbar, siehe inkonsistente Werte für newA und newB wie beschrieben in JLS 17.11, dass kann hier nicht passieren, weil Sie begangen werden, zu dem Speicher, bevor der andere thread bekommt ahold einen Verweis auf die neue f = new Foo() Instanz, die Sie erstellt haben... das ist sicher eine Zeit-Veröffentlichung. Auf der anderen Seite, wenn Sie schrieb

    void updateFoo(int newA, int newB) {
  f = new Foo(); theFoo = f;     
  f.a = newA; f.b = newB;
}


    In diesem Fall ist aber die Synchronisierung Probleme sind relativ transparent, und die Bestellung ist die am wenigsten Ihrer sorgen. Für einige nützliche Anleitungen auf volatil, nehmen Sie einen Blick auf diese developerWorks Artikel.

    Jedoch, haben Sie möglicherweise ein Problem bei separaten reader threads sehen kann, wird der alte Wert für theFoo für unbegrenzte Mengen an Zeit. In der Praxis ist dies nur selten geschieht. Aber die JVM erlaubt ist, cache entfernt den Wert des theFoo Referenz in einem anderen thread-Kontext. Ich bin ziemlich sicher, dass die Kennzeichnung theFoo als volatile werde diese Adresse, so wird jede Art von synchronizer oder AtomicReference.

    • Du hast Recht, es kann und es ist eigentlich in einem Konstruktor in meinem eigentlichen code. Mir war nicht bewusst, gab es keine spezifischen Regeln für die Veröffentlichung für Konstruktoren, so Suche ich in diese Richtung. Danke für den Tipp 🙂
    • Also ich kann mich irren über spezielle Behandlung für Konstruktoren. Ich glaube, dass diese Besondere Behandlung nur gilt für final Felder (die ich denke, dir wäre in diesem Fall, wenn Sie haven ' T gemacht, dass explizite). Siehe cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf, um alle Verweise zu Konstruktoren sind im Rahmen der Initialisierung final Felder.
    • Boah. Vielen Dank, für die vielen Recherchen und die ausführliche und leicht verständliche Erklärung. Jetzt weiß ich, wie ich schreiben sollte, mein code. Ich danke Ihnen sehr.
    • Nur der Vollständigkeit halber, werde ich hinzufügen, dass, wenn Sie versuchen, um zu maximieren die Lesbarkeit, ich würde vergessen, alles, und einfach synchronisieren Sie die beiden Methoden.
    • Ich bekomme es nicht. Warum gehst du nicht einfach erklären, theFoo volatil. Sie können dann loszuwerden synchronisiert. Sie sparen auch Zeit, weil eine volatile schreiben, ist etwa 1/3 der Kosten für einen monitor betreten/verlassen. Ich sehe es an Ihre Antwort, aber ich würde behaupten, wäre es besser lesbar.
    • V: Meine Antwort beinhaltet die "nur verwenden, flüchtige" Antwort, aber ich denke, viele würden dem widersprechen, dass es besser lesbar wird. In meiner Erfahrung volatile ist ein viel-missverstanden Ecke von Java, erfordert eine sorgfältige Analyse, um sicherzustellen, dass er richtig ist, und kann leicht verloren gehen, wie die Klasse ist im Laufe der Zeit entwickelt. Ich habe versucht, die Antwort zu geben auf die Frage, aber beachten Sie auch, dass synchronized wird verstanden werden, indem mehr Leute, die dauerhaft ist über einen größeren Bereich verwendet, und ist wahrscheinlich bevorzugt es sei denn, es ist ein gut verstanden-performance-Treiber.
    • V: JCiP rät von Verwendung von flüchtigen, außer, wenn Sie "vereinfachen implementieren[ation] und verif[Erinnerungen]", und weist die Umsetzer in Richtung Atomic-Variablen, die sich "oft verwendet werden, als bessere volatile Variablen." (JCiP 3.1.1), Während ich mich normalerweise nicht auf Autorität berufen, JCiP hat einen guten Ruf, und ich Neige dazu, zu verschieben, es sei denn, ich habe konkrete Beweise für das Gegenteil.
    • Beachten Sie auch, dass volatile funktioniert nur zuverlässig in dem speziellen Fall, dass unveränderliche Objekte. Während ich schob den Fragesteller in dieser Richtung, ich bin mir nicht sicher, wir können davon ausgehen... wenn die theFoo ist wirklich wandelbar ist oder wird also in Zukunft volatile wird keine Garantie für die Bestellung, die Konsistenz oder die Sichtbarkeit der Zukunft schreibt, um seine Felder.
    • Ich bin damit einverstanden, dass es wäre besser, eine AtomicReference. Aber das volatile-Schlüsselwort seit 1.5 sorgt, passiert, bevor Sie bestellen. Es wird garantiert nicht die Anforderung, die Konsistenz und Transparenz genauso wie eine AtomicReference würde. Ich argumentierte, dass in Ihrem Beispiel, halten alle anderen Codes die gleichen, die den Bereich volatile wäre meiner Meinung nach eine bessere Umsetzung.
    • Zur besseren Lesbarkeit können Sie machen, dass argument. Es ist mehr offensichtlich, dass die variable theFoo bewacht wird gegen jedes Objekt, dessen Synchronisation auf. Aber ich denke, wenn Sie nicht über akzeptable Dokumentation, die auf das Feld selbst dann kann es auch sein verloren in der Zukunft. Einer der größten Punkte in JCiP zu dokumentieren, ist thread-Sicherheit.
    • Versehentlich gelöscht, dieser Kommentar - @andersoj Letzten Punkt, den ich verpasst eines der letzten Dinge, die du geschrieben hast. Heute haben die meisten Prozessoren bieten flüchtigen liest nah zu sein, ein normales Lesen. Wenn wir gehen für den reinen Durchsatz, und es gibt eine Menge liest, ist der Unterschied ziemlich erheblich.
    • V: Das ist eine gute information... ich Frage mich, ob es eine Quelle, die quantifiziert, die irgendwie... (aus google scholar...)
    • dein argument, dass flüchtige funktioniert nur korrekt mit der unveränderlichen Objekte ist nicht korrekt (es war unter der alten JMM aber unter den neuesten JMM es nicht - siehe 17.4.7) – alle Schreibvorgänge vor dem volatile-schreiben passieren-bevor die flüchtigen Lesen. Wie ich schon sagte, anderswo Finale ist so ziemlich immer vorzuziehen, jedenfalls aber für seine zusätzliche Garantien.
    • Wesley-Smith vereinbart, ich denke, wir kreuzten, wie ich reagiert wurde... kann Sie Lesen den neuen text ein und sehen Sie, wenn ich habe es jetzt?
    • JMM: java.sun.com/docs/books/jls/third_edition/html/memory.html
    • Y, insbesondere 17.4.4
    • sieht alles gut jetzt große Antwort.

    InformationsquelleAutor
  • 4

    Haben eine unveränderliche Foo mit der definitiven a-und b-Felder löst die Sichtbarkeit Probleme mit den default-Werten, aber so hat das theFoo volatil.

    Persönlich ich mag mit unveränderlichen Wert-Klassen sowieso, da Sie viel schwieriger zu missbrauchen.

    • Wesley-Smith: Siehe meine Antwort--ich glaube in diesem Fall haben Sie zu tun, sowohl um die gewünschten Garantien.
    • ein schreiben auf eine volatile garantiert eine happens-before Beziehung (die Foo ist sicher veröffentlicht). Dies bedeutet, dass alles, was passiert ist-vor dem schreiben theFoo zu sehen sein wird, wenn das neue foo-Wert verfügbar ist. Wie gesagt, die unveränderliche Klasse " Foo " vorzuziehen, da damit garantiert niemand wird in der Lage sein, um den Status zu ändern oder versehentlich-um den code und ändern Sie die flüchtigen write Semantik, aber flüchtig ist genug auf seine eigene.
    • auch er ausdrücklich fest, dass die Anforderung für eine richtig konstruiert, Foo, nicht unbedingt die neueste, also volatil ist nicht erforderlich, das neueste Objekt-Garantie (die Sichtbarkeit von allem zu schreiben), daher eine unveränderliche Foo mit einer statischen Initialisierer zu erstellen, die einen nicht-null-ersten theFoo garantieren einen nicht-null-theFoo zu allen Zeiten.
    • Wesley-Smith: Also ich denke du hast mich überzeugt, obwohl ich muss gestehen, es ist wirklich schwer zu Graben diese aus der verfügbaren Dokumentation... Schreibe ich ein anderes ändern, um meine Antwort zu erfassen, was ich denke, ich habe gelernt...
    • ja neu: der "flüchtige ist nicht notwendig," außer, dass es ohne die Wartezeit, um updates von anderen threads ist völlig unbegrenzt. Während der Fragesteller schert sich nicht genau, welches update gesehen, er macht die Pflege, die updates sind schließlich gesehen. Mein Verständnis ist, dass, ohne flüchtige oder andere Kante, die den Leser thread ist frei, cache den Wert effektiv für immer, ja?
    • Wollen Sie vielleicht einen Kommentar hier: stackoverflow.com/questions/3488703/...
    • Sofort verpflichten, Speicher notwendig ? Ja, und Nein. @andersoj, Sie haben ganz Recht, die besagt, dass in Abwesenheit einer anderen Kante, die anderen threads sind nie garantiert, um eine Veränderung zu sehen. Auf der anderen Seite, wie ich Angaben in der ursprünglichen Frage, alle meine threads stoßen memory-Barrieren ziemlich Häufig, und Sie werden in Kürze Begehen, um Speicher trotzdem, immer schnell genug für meine Bedürfnisse. Also, meine Funktion ist es nicht erforderlich, obwohl der code in der Frage nicht klar machen. Aber... es ist besser lesbar und weniger Fehler-anfällig zu machen, volatil sowieso. Also mache ich es.
    • Und dann wieder, während ich bin nicht sehr begeistert von der syntax AtomicReference, es hat zwei sehr deutliche Vorteile gegenüber einer einfach volatile Feld : 1. es macht unmissverständlich offensichtlich ist dies eine lock-free shared object. AtomicReference ist ziemlich eindeutig, dass ich Baue, naja, eine Atomare Referenz. 2. Es zwingt client-code die Verwendung von get() und jemand gesund wird-cache den Wert in eine lokale variable. Ich kann mir vorstellen client-code Zugriff auf theFoo.ein und theFoo.b getrennt, und bekommen Werte, die sind beide richtig, aber nicht mit einander übereinstimmen. Ich sehe nicht, theFoo.get().ein und theFoo.get().b so viel.
    • Beachten Sie den Unterschied zwischen deinem thread, zu Begehen, um Speicher und andere threads Spülen der cache-und Lesen aus dem Speicher. Beide erfolgen müssen-und in dem Fall von der lese-side, es ist gefährlich zu Vertrauen, dass dies geschieht, es sei denn, diese threads haben einige andere Interaktion mit dieser Referenz/Objekt... deine situation ist sehr nahe an der kanonischen "wie stoppe ich einen thread?" - Frage, z.B. hier cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#volatile
    • Ah, ja, du hast Recht, ich hatte nicht daran gedacht. Passiert, mein Leser threads haben auch memory-Barrieren. Aber es ist schön zu betonen. Sowieso kein problem mit der AtomicReference oder mit der flüchtigen Lösung.

    InformationsquelleAutor Jed Wesley-Smith
    • Schreibe einen Kommentar