« C’est quoi la différence entre « imprévisible » (Java) et « ça dépend » (C++) ? La même qu’entre un bon et un mauvais chasseur ? »
Quelque soit le langage, si celui-ci autorise des accès concurrents non-protégés, le résultat est nécessairement aléatoire. Ce n'est pas obligatoirement un « mauvais » résultat (certains algorithmes en tirent même parti), mais généralement ce n'est pas ce qu'on recherche.
Ceci étant dit:
Le modèle mémoire de Java (JMM) spécifie que si tu codes sans passer par des outils de synchro (locks, utilisation de volatile, etc), alors le comportement à l'exécution est indéfini. Si tu utilises les mécanismes de synchro, alors tu auras une exception à l'exécution (ou peut-être même une tape sur la main à la compil si tu as des outils intelligents).
Dans le cas d'une utilisation correcte des méthodes de synchronisation, alors le JMM garantit une exécution suivant une politique appelée « sequential consistency » (SC). En gros, Du point de vue du thread qui s'exécute, l'ordre des instructions (au sens instruction load ou store dans la jvm) doit être celui spécifié dans le programme original, et toute écriture sur un des objets mémoire que le thread manipule (lecture ou écriture) doit lui apparaître selon l'ordre total de tous les threads qui s'exécutent en même temps.
Je parle ici de programmes dits « data race free » i.e. qui ont des accès synchronisés aux variables partagées.
Java a toujours eu un modèle mémoire concernant les accès concurrents, mais celui-ci est cassé/buggé. En 2004 une refonte du JMM a été commencée (et appliquée à partir de Java 1.5 si je me souviens bien).
Le cas de C++ diffère, dans le sens où les threads ne faisaient pas partie du langage initialement. La prochaine norme va les intégrer au langage, ce qui signifie que C++ doit prendre position sur la façon dont les opérations en mémoire doivent être perçues par le programmeur et à l'exécution.
C++MM suit plus ou moins le même modèle (SC pour les programmes sans accès concurrents aux données), avec quelques subtilités où ils précisent explicitement certains comportements indéfinis ou dépendants de l'implémentation (pour autoriser certaines optimisations impossibles dans le cas SC pur).
[^] # Re: Bonne nouvelle
Posté par lasher . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 2.
Quelque soit le langage, si celui-ci autorise des accès concurrents non-protégés, le résultat est nécessairement aléatoire. Ce n'est pas obligatoirement un « mauvais » résultat (certains algorithmes en tirent même parti), mais généralement ce n'est pas ce qu'on recherche.
Ceci étant dit:
Le modèle mémoire de Java (JMM) spécifie que si tu codes sans passer par des outils de synchro (locks, utilisation de volatile, etc), alors le comportement à l'exécution est indéfini. Si tu utilises les mécanismes de synchro, alors tu auras une exception à l'exécution (ou peut-être même une tape sur la main à la compil si tu as des outils intelligents).
Dans le cas d'une utilisation correcte des méthodes de synchronisation, alors le JMM garantit une exécution suivant une politique appelée « sequential consistency » (SC). En gros, Du point de vue du thread qui s'exécute, l'ordre des instructions (au sens instruction load ou store dans la jvm) doit être celui spécifié dans le programme original, et toute écriture sur un des objets mémoire que le thread manipule (lecture ou écriture) doit lui apparaître selon l'ordre total de tous les threads qui s'exécutent en même temps.
Je parle ici de programmes dits « data race free » i.e. qui ont des accès synchronisés aux variables partagées.
Java a toujours eu un modèle mémoire concernant les accès concurrents, mais celui-ci est cassé/buggé. En 2004 une refonte du JMM a été commencée (et appliquée à partir de Java 1.5 si je me souviens bien).
Le cas de C++ diffère, dans le sens où les threads ne faisaient pas partie du langage initialement. La prochaine norme va les intégrer au langage, ce qui signifie que C++ doit prendre position sur la façon dont les opérations en mémoire doivent être perçues par le programmeur et à l'exécution.
C++MM suit plus ou moins le même modèle (SC pour les programmes sans accès concurrents aux données), avec quelques subtilités où ils précisent explicitement certains comportements indéfinis ou dépendants de l'implémentation (pour autoriser certaines optimisations impossibles dans le cas SC pur).