Technische Realisierung von Atomic Datentypen

[marco81]

Hallo Kollegen,

was unterscheidet einen Integer von einem Atomic Integer technisch gesehen? Welche Unterschiede treten in der JVM auf?

 

[thecain]

Atomic Access (The Java™ Tutorials > Essential Java Classes > Concurrency)

docs.oracle.com

 

[Oneixee5]

Hier ist eine gute Zusammenfassung: https://www.baeldung.com/java-atomic-variables

 

[123neu]

Unterschiede sind, dass die Methoden des AtomicInteger synchronized, also threadsicher sind. Zudem kann dessen Wert nur über Methoden bezogen und gesetzt werden.

Auch ein volatiles int hat zum Beispiel keine atomare Schreiboperation, es kann also passieren dass bei der Zuweisung a=b; ein Thread einen ungültigen Wert liest der weder a noch b ist. Auch wenn das in der Praxis sehr rar vorkommt. Mit AtomicInteger wird das vermieden.

 

[Oneixee5]

dass die Methoden des AtomicInteger synchronized, also threadsicher sind.

Das ist eben nicht so. AtomicTypes sind nicht blockierend.

 

[httpdigest]

Auch ein volatiles int hat zum Beispiel keine atomare Schreiboperation, es kann also passieren dass bei der Zuweisung a=b; ein Thread einen ungültigen Wert liest der weder a noch b ist. Auch wenn das in der Praxis sehr rar vorkommt. Mit AtomicInteger wird das vermieden.

Und auch das ist nicht korrekt.

Das Java Memory Model garantiert, dass Schreib- und Lesezugriffe auf volatile Variablen immer atomar sind, also kein Thread nur einen "Teilbereich" des Datentypen lesen kann während ein anderer Thread gerade schreibt.
Und sogar non-volatile ints sind atomar. Also, selbst, wenn man ein int nicht als volatile markiert, können solche "Zwischenzustände" nicht gelesen werden.
Nur für long und double gibt es eine explizite Unterscheidung bezüglich Atomarität: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7
Damit wurde der Fall mit aufgenommen, wenn man die JVM als 32-bit Prozess laufen lässt und 64-bit Werte (eben long oder double) schreibt - da ein 32-bit Prozess keine 64-bit Speicher/-Memorytransaktionen verwendet. Hier garantiert das JLS nur Atomarität auf 32-bit Teilbereichen.
Aber für als volatile markierte Variablen ist der Zugriff immer atomar (auch für longs und doubles)!

kleiner Hinweis, um das obige nicht falsch zu verstehen: Atomar bedeutet hier nicht, dass jede Operation wie etwa i++ auf einer Variablen i atomar ist, sondern direkte Lese- und Schreibzugriffe sind atomar! i++ sind drei Operationen: i lesen, inkrementieren und auf i schreiben.

 

[123neu]

Das ist eben nicht so. AtomicTypes sind nicht blockierend.

Ja stimmt, sie sind volatile, was synchronized und threadsicher gleichkommt.

Auch ein volatiles int hat zum Beispiel keine atomare Schreiboperation, es kann also passieren dass bei der Zuweisung a=b; ein Thread einen ungültigen Wert liest der weder a noch b ist. Auch wenn das in der Praxis sehr rar vorkommt. Mit AtomicInteger wird das vermieden.

Und hier muss das volatiles gestrichen werden, also:
Einfache Variablen haben zum Beispiel keine atomare Schreiboperationen, usw.

Und auch das ist nicht korrekt

Wenn du ein bisschen abwarten könntest... Alles bis auf volatiles war korrekt. 🙄

 

[httpdigest]

Einfache Variablen haben zum Beispiel keine atomare Schreiboperationen, usw.

Das gilt allerdings, wie gesagt, nur für 64-bit Werte (also nur long und double). Alle kleineren Datentypen sind atomar. Immer. Auch ohne volatile.
Und praktisch gesehen sind auf 64-bit Systemen auch long und double atomar. Das Java Memory Model ist sehr "schwach" und existierende Systeme/Implementierungen sind sehr viel "robuster".

 

[123neu]

Das gilt allerdings, wie gesagt, nur für 64-bit Werte (also nur long und double). Alle kleineren Datentypen sind atomar. Immer. Auch ohne volatile.
Und praktisch gesehen sind auf 64-bit Systemen auch long und double atomar. Das Java Memory Model ist sehr "schwach" und existierende Systeme/Implementierungen sind sehr viel "robuster".

In solchen Fällen das "volatile" wegzulassen halte ich aber für unleserlichen Code. Deshalb von Anfang an richtig angewöhnen.

 

[httpdigest]

Du verkennst hier aber, dass in diesem Fall "volatile" überhaupt nichts mit Atomarität zu tun hat, sondern mit Sichtbarkeit bzw. etablieren einer "happens-before" Relation. Letztlich sorgt volatile dafür, dass Caches beim Schreiben geflushed und beim Lesen invalidiert werden und, dass der JIT Compiler und die CPU keine Zugriffe/Operationen umsortieren dürfen.
Es stellt also nicht nur Atomarität sicher, sondern auch direkte Sichtbarkeit der Zugriffe.

 

[marco81]

e Unterscheidung bezüglich Atomarität: https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.7
Damit wurde der Fall mit aufgenommen, wenn man die JVM als 32-bit Prozess laufen lässt und 64-bit

 

[marco81]

Danke für eure Antworten. Ganz besonderes Dankeschön an httpdigest und 123neu die sich besonders viel Zeit genommen haben.

 

[123neu]

123neu die sich besonders viel Zeit

der! 🤣

 

[kneitzel]

der! 🤣

OT, aber Deutsch ist doch eigentlich ganz einfach: Das "die" bezog sich auf httpdiggest und 123neu -> mehrere Personen und daher ist es korrekt zu schreiben "die sich besonders viel Zeit genommen haben". Das Plural zeigt sich ja auch im "haben".

 

[123neu]

Ok, 3. Person Plural... Da fehlte aber mindestens ein Komma.

 

[marco81]

Ok, 3. Person Plural... Da fehlte aber mindestens ein Komma.

Ist doch alles okay. Danke für deine zeit

 

[mihe7]

@marco81, bei so etwas braucht Du eigentlich nur die Fleisch gewordene JVM (aka @httpdigest) zu fragen. Der träumt von solchen Dingen - in Bytecode, versteht sich.