Pourquoi ce programme Java se termine-t-il malgré cela, apparemment il ne devrait pas (et ne l'a pas fait)?

Aujourd'hui, une opération délicate dans mon laboratoire s'est complètement mal passée. Un actionneur sur un microscope électronique a dépassé ses limites et, après une chaîne d'événements, j'ai perdu 12 millions de dollars d'équipement. J'ai réduit plus de 40 000 lignes dans le module défectueux à ceci:

import java.util.*;

class A {
    static Point currentPos = new Point(1,2);
    static class Point {
        int x;
        int y;
        Point(int x, int y) {
            this.x = x;
            this.y = y;
        }
    }
    public static void main(String[] args) {
        new Thread() {
            void f(Point p) {
                synchronized(this) {}
                if (p.x+1 != p.y) {
                    System.out.println(p.x+" "+p.y);
                    System.exit(1);
                }
            }
            @Override
            public void run() {
                while (currentPos == null);
                while (true)
                    f(currentPos);
            }
        }.start();
        while (true)
            currentPos = new Point(currentPos.x+1, currentPos.y+1);
    }
}

Quelques échantillons de la sortie que je reçois:

$ java A
145281 145282
$ java A
141373 141374
$ java A
49251 49252
$ java A
47007 47008
$ java A
47427 47428
$ java A
154800 154801
$ java A
34822 34823
$ java A
127271 127272
$ java A
63650 63651

Puisqu'il n'y a pas d'arithmétique à virgule flottante ici, et nous savons tous que les entiers signés se comportent bien en cas de débordement en Java, je pense qu'il n'y a rien de mal à ce code. Cependant, malgré la sortie indiquant que le programme n'a pas atteint la condition de sortie, il a atteint la condition de sortie (il était à la fois atteint et non atteint?). Pourquoi?

J'ai remarqué que cela ne se produit pas dans certains environnements. Je suis sur OpenJDK 6 sur Linux 64 bits.

De toute évidence, l'écriture dans currentPos ne se produit pas avant sa lecture, mais je ne vois pas comment cela peut être le problème.

currentPos = new Point(currentPos.x+1, currentPos.y+1);fait quelques choses, y compris l'écriture de valeurs par défaut dans xet y(0), puis l'écriture de leurs valeurs initiales dans le constructeur. Étant donné que votre objet n'est pas publié en toute sécurité, ces 4 opérations d'écriture peuvent être librement réorganisées par le compilateur / JVM.

Du point de vue du thread de lecture, c'est donc une exécution légale à lire xavec sa nouvelle valeur mais yavec sa valeur par défaut de 0 par exemple. Au moment où vous atteignez l' printlninstruction (qui est d'ailleurs synchronisée et influence donc les opérations de lecture), les variables ont leurs valeurs initiales et le programme imprime les valeurs attendues.

Marquer currentPoscomme volatilegarantira une publication sûre puisque votre objet est effectivement immuable - si dans votre cas d'utilisation réel l'objet est muté après la construction, les volatilegaranties ne seront pas suffisantes et vous pourriez voir à nouveau un objet incohérent.

Alternativement, vous pouvez rendre l' Pointimmuable qui assurera également une publication sûre, même sans utilisation volatile. Pour atteindre l'immuabilité, il vous suffit de marquer xet de yterminer.

En remarque et comme déjà mentionné, synchronized(this) {}peut être traité comme un no-op par la JVM (je comprends que vous l'avez inclus pour reproduire le comportement).

Comme il currentPosest modifié en dehors du fil, il doit être marqué comme volatile:

static volatile Point currentPos = new Point(1,2);

Sans volatilité, le thread n'est pas garanti de lire les mises à jour de currentPos qui sont effectuées dans le thread principal. Par conséquent, de nouvelles valeurs continuent d'être écrites pour currentPos, mais le thread continue d'utiliser les versions mises en cache précédentes pour des raisons de performances. Étant donné qu'un seul thread modifie currentPos, vous pouvez vous en tirer sans verrous, ce qui améliorera les performances.

Les résultats sont très différents si vous ne lisez les valeurs qu'une seule fois dans le thread pour les utiliser dans la comparaison et leur affichage ultérieur. Lorsque je fais ce qui suit xs'affiche toujours en tant que 1et yvarie entre 0et un grand entier. Je pense que le comportement de celui-ci à ce stade est quelque peu indéfini sans le volatilemot - clé et il est possible que la compilation JIT du code y contribue. De plus, si je commente le synchronized(this) {}bloc vide , le code fonctionne également et je soupçonne que c'est parce que le verrouillage provoque un retard suffisant currentPoset que ses champs sont relus plutôt qu'utilisés à partir du cache.

int x = p.x + 1;
int y = p.y;

if (x != y) {
    System.out.println(x+" "+y);
    System.exit(1);
}

Vous avez une mémoire ordinaire, la référence 'currentpos' et l'objet Point et ses champs derrière elle, partagés entre 2 threads, sans synchronisation. Ainsi, il n'y a pas d'ordre défini entre les écritures qui arrivent à cette mémoire dans le thread principal et les lectures dans le thread créé (appelez-le T).

Le thread principal effectue les écritures suivantes (en ignorant la configuration initiale de point, px et py auront des valeurs par défaut):

• à px
• à py
• à currentpos

Parce qu'il n'y a rien de spécial à propos de ces écritures en termes de synchronisation / barrières, le runtime est libre pour permettre au thread T de les voir se produire dans n'importe quel ordre (le thread principal voit bien sûr toujours les écritures et les lectures ordonnées selon l'ordre du programme), et se produit à tout moment entre les lectures de T.

Alors T fait:

1. lit currentpos en p
2. lire px et py (dans l'un ou l'autre ordre)
3. comparer et prendre la branche
4. lire px et py (dans les deux cas) et appeler System.out.println

Étant donné qu'il n'y a pas de relations de classement entre les écritures dans main et les lectures dans T, il existe clairement plusieurs façons de produire votre résultat, car T peut voir l'écriture de main dans currentpos avant les écritures dans currentpos.y ou currentpos.x:

1. Il lit currentpos.x en premier, avant que l'écriture x ne se produise - obtient 0, puis lit currentpos.y avant que l'écriture y se produise - obtient 0. Compare evals à true. Les écritures deviennent visibles pour T. System.out.println est appelé.
2. Il lit currentpos.x en premier, après que l'écriture x s'est produite, puis lit currentpos.y avant que l'écriture y se soit produite - obtient 0. Compare evals à true. Les écritures deviennent visibles pour T ... etc.
3. Il lit currentpos.y en premier, avant que l'écriture y n'ait eu lieu (0), puis lit currentpos.x après l'écriture x, ce qui est vrai. etc.

et ainsi de suite ... Il y a un certain nombre de courses de données ici.

Je soupçonne l'hypothèse erronée ici de penser que les écritures qui résultent de cette ligne sont rendues visibles sur tous les threads dans l'ordre du programme du thread qui l'exécute:

currentPos = new Point(currentPos.x+1, currentPos.y+1);

Java n'offre aucune garantie (ce serait terrible pour les performances). Quelque chose de plus doit être ajouté si votre programme a besoin d'un ordre garanti des écritures par rapport aux lectures dans d'autres threads. D'autres ont suggéré de rendre les champs x, y définitifs ou de rendre volatils les courants.

• Si vous définissez les champs x, y comme définitifs, Java garantit que l'écriture de leurs valeurs se produira avant le retour du constructeur, dans tous les threads. Ainsi, comme l'affectation à currentpos se fait après le constructeur, le thread T est garanti de voir les écritures dans le bon ordre.
• Si vous rendez la position actuelle volatile, Java garantit qu'il s'agit d'un point de synchronisation qui sera ordonné au total par rapport aux autres points de synchronisation. Comme en général, les écritures sur x et y doivent se produire avant l'écriture dans currentpos, alors toute lecture de currentpos dans un autre thread doit également voir les écritures de x, y qui se sont produites auparavant.

L'utilisation de final présente l'avantage de rendre les champs immuables et permet ainsi la mise en cache des valeurs. L'utilisation de données volatiles entraîne une synchronisation à chaque écriture et lecture des positions actuelles, ce qui peut nuire aux performances.

Voir le chapitre 17 de la spécification du langage Java pour les détails sanglants: http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html

(La réponse initiale supposait un modèle de mémoire plus faible, car je n'étais pas sûr que la volatilité garantie par JLS était suffisante. ).

Vous pouvez utiliser un objet pour synchroniser les écritures et les lectures. Sinon, comme d'autres l'ont déjà dit, une écriture dans currentPos se produira au milieu des deux lectures p.x + 1 et py

new Thread() {
    void f(Point p) {
        if (p.x+1 != p.y) {
            System.out.println(p.x+" "+p.y);
            System.exit(1);
        }
    }
    @Override
    public void run() {
        while (currentPos == null);
        while (true)
            f(currentPos);
    }
}.start();
Object sem = new Object();
while (true) {
    synchronized(sem) {
        currentPos = new Point(currentPos.x+1, currentPos.y+1);
    }
}

Vous accédez à currentPos deux fois et ne garantissez pas qu'il n'est pas mis à jour entre ces deux accès.

Par exemple:

1. x = 10, y = 11
2. le thread de travail évalue px comme 10
3. le thread principal exécute la mise à jour, maintenant x = 11 et y = 12
4. thread de travail évalue py comme 12
5. le thread de travail remarque que 10 + 1! = 12, imprime et quitte donc.

Vous comparez essentiellement deux différents points .

Notez que même rendre currentPos volatile ne vous protégera pas de cela, car il s'agit de deux lectures distinctes par le thread de travail.

Ajouter un

boolean IsValid() { return x+1 == y; }

à votre classe de points. Cela garantira qu'une seule valeur de currentPos est utilisée lors de la vérification de x + 1 == y.