Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Étudiant
    Inscrit en
    août 2011
    Messages
    283
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : août 2011
    Messages : 283
    Points : 18 067
    Points
    18 067

    Par défaut Projet Valhalla : un incubateur d’idées et de fonctionnalités pour préparer le terrain pour Java 10

    Projet Valhalla : un incubateur d'évolutions pour préparer le terrain pour Java 10
    alors que Java 9 n’est pas attendu avant 2016

    Alors que Java 8 est sorti en mars dernier et que la prochaine version majeure n’est pas attendue avant 2016, un comité d’experts dirigé par Brian Goetz vient de voir le jour pour dresser les grandes lignes de Java 10.

    L’idée derrière ce nouveau projet dénommé Valhalla est de servir d’incubateur pour la version 10 de Java, en testant différentes évolutions possibles parmi les fonctionnalités qui doivent être supportées par le langage de programmation sur le long terme.

    Parmi les fonctionnalités et les idées d’améliorations qui seront étudiées par le projet, il est possible de citer les valeurs des types (Value Types), ce qui peut permettre une optimisation de la représentation mémoire des types tout en maintenant les mêmes performances. D’autres fonctionnalités sont aussi à l’étude, c’est le cas par exemple de la spécialisation des génériques (Generic Specialization) ainsi que l’amélioration des volatiles (enhanced volatiles).

    Le projet Valhalla tente aussi d’améliorer le langage Java en l’affectant à différents niveaux, comme le typage, le langage, la machine virtuelle ou les bibliothèques. Le projet a pour vocation de définir une sémantique claire au niveau de la machine virtuelle pour permettre un support égale pour le langage Java et les autres langages recourant à la JVM.

    Pour l’heure le projet n'en est encore qu'à ses balbutiements. L’annonce de sa création a été faite via la mailing list d’OpenJDK. Elle mentionne, entre autres, les membres du comité d’experts pilotant le projet ainsi que la version de base de Java qui sera utilisée (JDK9).

    Source : annonce du projet Valhalla

    Et vous ?

    Qu’en pensez-vous ?

  2. #2
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 169
    Points
    2 169

    Par défaut

    Jigsaw repoussé pour Java 10 dans 5... 4... 3...

  3. #3
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 868
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 868
    Points : 39 638
    Points
    39 638

    Par défaut

    Citation Envoyé par Arsene Newman Voir le message
    les valeurs des types (Value Types)
    En français on appelle plutôt ça les types valeur (par opposition aux types référence). C'est ce qui correspond aux struct de C# par exemple (ça doit aussi exister dans d'autres langages ; il me semble que Swift a aussi une notion de type valeur)

  4. #4
    Membre chevronné
    Avatar de la.lune
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    décembre 2010
    Messages
    534
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Comores

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : décembre 2010
    Messages : 534
    Points : 2 031
    Points
    2 031

    Par défaut

    Citation Envoyé par Traroth2 Voir le message
    Jigsaw repoussé pour Java 10 dans 5... 4... 3...
    S'il n y a pas de Jigsaw dans Java 9 que ce qu'il y aura vraiment dedans

  5. #5
    Membre actif
    Homme Profil pro
    Consultant communication & réseaux
    Inscrit en
    octobre 2013
    Messages
    85
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant communication & réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : octobre 2013
    Messages : 85
    Points : 204
    Points
    204

    Par défaut

    Nous espérons des optimisations de performances et corrections de bugs

  6. #6
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 546
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 546
    Points : 251 748
    Points
    251 748
    Billets dans le blog
    100

    Par défaut

    Java : le projet Valhalla validé par Oracle
    pour préparer le terrain aux futures évolutions de la plateforme

    Le projet Valhalla pour la plateforme Java prend forme. Annoncé il y a quelques mois par Brian Goetz, responsable du projet, celui-ci a été validé par Oracle.

    Le projet Valhalla est une sorte d’incubateur pour le développement des futures fonctionnalités de la plateforme Java. Celui-ci va tenter d’améliorer le langage Java en l’affectant à différents niveaux, comme le typage, le langage, la machine virtuelle ou les bibliothèques. Le projet a pour vocation de définir une sémantique claire au niveau de la machine virtuelle pour permettre un support égal pour le langage Java et les autres langages recourant à la JVM.

    La révision majeure dans la description actuelle du projet concerne les génériques. Les versions actuelles de Java ne permettent pas que les types génériques contiennent les types primitifs, et le compilateur Java supprime les détails du type contenu lors de la compilation. Cette approche de typage générique (effacement de type) représente l’un des aspects assez critiqués du système de types de Java.

    Le projet Valhalla explorera une nouvelle approche pour la gestion des types génériques, et espère produire une nouvelle forme de typage générique, qui permettra aux développeurs d’appliquer des génériques aux types primitifs. Ainsi, dans les futures versions de Java, des déclarations telles que List<int> pourront être valides en Java.

    D’autres modifications importantes sont également au menu comme les types valeurs, qui permettront une optimisation de la représentation mémoire des types tout en maintenant les mêmes performances. Les types valeurs auront pour objectif de combiner certaines propriétés des types primitifs et des types objets, pour donner naissance à un nouveau type, qui sera manipulé par le développeur comme un type primitif.

    Les développeurs intéressés par le projet peuvent rejoindre sa liste de diffusion sur le site d’OpenJDK. Brian Goetz a souligné dans l’annonce que le projet est encore à un stade embryonnaire, donc la communauté ne devrait pas s’attendre à trouver une technologie développée au sein de Valhalla dans JDK 9, dont la version finale est prévue pour 2016.

    Annonce du projet projet Valhalla

    Description du projet Valhalla
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  7. #7
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    419
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 419
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut Adieu C++

    Avec cette nouveauté :
    D’autres modifications importantes sont également au menu comme les types valeurs, qui permettront une optimisation de la représentation mémoire des types tout en maintenant les mêmes performances. Les types valeurs auront pour objectif de combiner certaines propriétés des types primitifs et des types objets, pour donner naissance à un nouveau type, qui sera manipulé par le développeur comme un type primitif.

    On peut dire adieu au C++ le point faible de java était ne pas pouvoire définir des types primtif comme les points et autre structure pour éviter d’allouer de la mémoire.
    reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..
    et on pourra écrire de jolie addition de vecteur V+U aussi rapide qu'en C++.

  8. #8
    Membre régulier
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2011
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2011
    Messages : 35
    Points : 103
    Points
    103

    Par défaut

    Citation Envoyé par super_navide Voir le message
    On peut dire adieu au C++

    Mais tout à fait...

  9. #9
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 868
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 868
    Points : 39 638
    Points
    39 638

    Par défaut

    Citation Envoyé par super_navide Voir le message
    reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..
    Bah dans ce cas tu peux faire du C#, qui fait tout ce que fait Java, a des types valeur et permet la surcharge d'opérateurs

    (bah oui, je prêche pour ma paroisse, hein )

  10. #10
    Membre extrêmement actif
    Avatar de benjani13
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    février 2010
    Messages
    553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France

    Informations professionnelles :
    Activité : Consultant en sécurité

    Informations forums :
    Inscription : février 2010
    Messages : 553
    Points : 2 476
    Points
    2 476

    Par défaut

    Citation Envoyé par super_navide Voir le message
    On peut dire adieu au C++ le point faible de java était ne pas pouvoire définir des types primtif comme les points et autre structure pour éviter d’allouer de la mémoire.
    reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..
    et on pourra écrire de jolie addition de vecteur V+U aussi rapide qu'en C++.
    Si les features du C++ t'interesse, pourquoi ne fais tu pas du C++ au lieu d'attendre que Java implémente ces features? Vous trouvez pas que c'est paradoxal? (le premier qui me répond "c'est pas faux" ).

    Citation Envoyé par tomlev Voir le message
    Bah dans ce cas tu peux faire du C#, qui fait tout ce que fait Java, a des types valeur et permet la surcharge d'opérateurs

    (bah oui, je prêche pour ma paroisse, hein )
    +1

    C#

  11. #11
    Membre expérimenté
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    juillet 2006
    Messages
    1 128
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 70
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : juillet 2006
    Messages : 1 128
    Points : 1 592
    Points
    1 592

    Par défaut

    Citation Envoyé par super_navide Voir le message
    reste plus qu'a pouvoir surcharger les opérateurs comme + - / etc..
    la surcharge d'opérateur a été refusée par l'équipe initiale de java pour éviter une confusion à la lecture du code.
    Un des points fondamentaux de la philosophie initiale était: ce qui est compilé est ce qui est explicitement écrit ... malheureusement des évolutions ultérieures ont un peu contourné cette règle
    mais la surcharge d'opérateur rend la lecture des codes C++ incroyablement difficile , et les programmeurs en abusent en violant allégrement la sémantique de l'opérateur.... vade retro satanas ...
    (quoiqu'en Scala il y a un point de vue plus amusant sur la question, voir aussi en Groovy ... mais en Java j'espère que cette demande n'aboutira jamais )
    edit: C# c'est la philosophie Microsoft: vous en voulez? alors en voilà! Peu importe si ça abouti à des formalismes peu en accord avec les règles du génie Logiciel (ou à des incohérences: je pense ici à la vision Microsoft de SQL qui donne un sens à des expressions illégales parce que les utilisateurs font souvent l'erreur ... alors ils donnent un sens à ce qui n'en a pas!)
    J'ai des principes: je peux toujours trouver une bonne raison pour les contredire .... mais j'ai des principes!
    (un peu de pub pour mon site: http://scrountch.info/java )

  12. #12
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    419
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 419
    Points : 0
    Points
    0
    Billets dans le blog
    1

    Par défaut n'importe quoi

    et les programmeurs en abusent en violant allégrement la sémantique de l'opérateur.... vade retro satanas ...
    Quel sémanatique de l'opérateur le symbol multiplication en math est utilisé pour les matrices et pour les nombre et ca sémantique n'est pas la même
    sur les matrice ils perd la commutativité et la transitivité.
    Donc le viol de sémantique n'existe pas.
    encore une regle stupide que certain informaticien ce donne................

  13. #13
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 247
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 247
    Points : 3 394
    Points
    3 394
    Billets dans le blog
    12

    Par défaut

    Bonjour,

    J'ai lu la JEP 193 concernant l'évolution de "volatile" mais je n'ai pas tout à fait saisi l'objectif de ".volatile".

    Est-ce qu'en faisant :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    // Exemple de la JEP
    class Usage {
        volatile int count;
        int incrementCount() {
            return count.volatile.incrementAndGet();
        }
    }
    L'idée c'est de faire quelque chose comme :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    class Usage {
        volatile int count;
        int incrementCount() {
            synchronized {
                return count.incrementAndGet();
            }
     
            return 0;
        }
    }
    ?

    Merci
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  14. #14
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 930
    Points : 22 979
    Points
    22 979
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    J'ai lu la JEP 193 concernant l'évolution de "volatile" mais je n'ai pas tout à fait saisi l'objectif de ".volatile".
    Non.

    L'idée c'est d'avoir le même mécanisme que les classes AtomicInteger, etc. qui n'ont pas recours à la synchronisation.




    Il faut savoir que les seules opérations atomiques c'est l'affectation d'une valeur :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    count = 15;
    // ou 
    int temp = count;


    Mais dès qu'il y a un calcul au milieu on n'est plus atomique, par exemple une incrémentation :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    count += 1; // ou count++
    En effet cela se décompose en fait en plusieurs instructions, que l'on pourrait représenter comme cela (en vrai c'est du bytecode, mais pour l'exemple je laisse en java) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int next = count;
    next++;
    count = next;
    Le problème c'est que si un autre thread modifie "count" entre ces deux opérations on se retrouve avec une valeur incorrect.

    Par exemple si tu as deux threads qui incrément de 1 en même temps tu peux avoir cela :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    int count = 0; // etat initial
     
    count += 1; // thread 1
    count += 1; // thread 2
    On pourrait penser que le résultat sera forcément "2", mais ce n'est pas garantie.
    En effet en décomposant on a en fait ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    int count = 0; // etat initial
     
    int next1 = count; // thread 1 (count vaut 0)
    next1++; // thread 1
    count = next1; // thread 1
     
    int next2 = count; // thread 2  (count vaut 1)
    next2++;  // thread 2
    count = next2; // thread 2
    Sauf que l'ordonnanceur peut nous jouer des tours, et on obtient alors une exécution qui ressemble à quelque chose comme cela :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    int count = 0; // etat initial
     
    int next1 = count; // thread 1 (count vaut 0)
    int next2 = count; // thread 2 (count vaut 0)
     
    next1++; // thread 1
    next2++; // thread 2
     
    count = next1; // thread 1
    count = next2; // thread 2
    Du coup next1 et next2 valent tous les deux "1", et count prend finalement la valeur "1" alors qu'on l'a incrémenté deux fois !



    En clair entre le moment ou on fait notre calcul et le moment ou on affecte le résultat dans la variable, la variable a été modifié par un autre thread
    Du coup on devrait avoir un résultat différent, et notre calcul fait "disparaitre" la modif précédente...



    En fait les classes AtomicXXX se base sur le compareAndSet, qui permet d'affecter une variable seulement si sa valeur correspond bien à celle indiqué.
    Du coup l'incrémentation correspond plutôt à ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    int old = count;
    int next = old + 1;
    count.volatile.compareAndSet(old, next); // ne marche QUE si la valeur de count == old
    L'idée c'est donc de faire cela dans une boucle, jusqu'à ce que compareAndSet() fonctionne.
    Ainsi si "count" a été modifié par un autre thread entre temps, on reprend le calcul avec la valeur modifié et on réessaye.


    C'est grosso-modo ce que font les méthodes d'AtomicInteger.
    Cela peut paraitre curieux, mais c'est plus efficace que la synchronisation (cela n'a quasiment aucun "coût" lorsque la variable n'est pas modifié entre temps).
    C'est même plus sûr car il n'y a pas forcément besoin d'utiliser synchronized sur toutes les utilisations de la variable...


    L'objectif de la JEP c'est de permettre cela directement sur un attribut primitif, sans pour autant passer par les classes AtomicXXX...


    a++

  15. #15
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 247
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 247
    Points : 3 394
    Points
    3 394
    Billets dans le blog
    12

    Par défaut

    Bonsoir,


    Merci pour les explications adiGuba , je connais déjà plus ou moins le comportement des variables dans un environnement multi-thread. Ce que je ne connais pas par contre, c'est le mécanisme interne des AtomicXXX et sa différence par rapport synchronized.

    Donc si je comprends bien : ".volatile" va faire comme AtomicXXX (qui n'utilise pas synchronized), mais en simplifiant la syntaxe lourde de AtomicXXX.

    J'ai donc décidé d'aller regarder l'implémentation de la méthode compareAndSet() de AtomicInteger pour essayer de comprendre le mécanisme de la "boucle" dont tu fais référence. La méthode compareAndSet() fait intervenir la méthode native compareAndSwapInt() du type sun.misc.Unsafe, on tombe sur du code ASM :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    // Version Linux :
    #define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
    // ... 
    inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
      int mp = os::is_MP();
      __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl %1,(%3)"
                        : "=a" (exchange_value)
                        : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
                        : "cc", "memory");
      return exchange_value;
    }
     
     
    // Version Windows :
    #define LOCK_IF_MP(mp) __asm cmp mp, 0  \
                           __asm je L0      \
                           __asm _emit 0xF0 \
                           __asm L0:
    // ...
    inline jint     Atomic::cmpxchg    (jint     exchange_value, volatile jint*     dest, jint     compare_value) {
      // alternative for InterlockedCompareExchange
      int mp = os::is_MP();
      __asm {
        mov edx, dest
        mov ecx, exchange_value
        mov eax, compare_value
        LOCK_IF_MP(mp)
        cmpxchg dword ptr [edx], ecx
      }
    }
    L'assembleur n'est pas ma tasse de thé, je vois bien que la clé se situe au niveau de l'instruction cmpxchg et qu'il y a un saut dans les 2 cas, mais le saut se situe vers le bas, donc je ne vois pas de "boucle" mais plutôt un lock avec une sorte de signal...
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  16. #16
    Membre averti Avatar de M_Makia
    Homme Profil pro
    Consultant .Net
    Inscrit en
    février 2008
    Messages
    119
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant .Net
    Secteur : Industrie

    Informations forums :
    Inscription : février 2008
    Messages : 119
    Points : 314
    Points
    314

    Par défaut

    C'est une très bonne nouvelle.
    La langage Java accuse d'un retard non négligeable par rapport à d'autres langages (Scala, Python, C# ...).
    Il est temps de dépoussiérer un peu tout ça ^^

  17. #17
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 930
    Points : 22 979
    Points
    22 979
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    L'assembleur n'est pas ma tasse de thé, je vois bien que la clé se situe au niveau de l'instruction cmpxchg et qu'il y a un saut dans les 2 cas, mais le saut se situe vers le bas, donc je ne vois pas de "boucle" mais plutôt un lock avec une sorte de signal...
    C'est normal la boucle n'est pas dans compareAndSet().
    Ce dernier se contente d'affecter la nouvelle valeur uniquement si la valeur actuelle correspond bien à celle qu'on indique.
    Bref compareAndSet() renvoi simplement true ou false selon qu'il a mit la valeur à jour ou pas.

    Après niveau assembleur je ne pourrais pas dire, mais il me semble que c'est une instruction des CPU...



    En fait la boucle se trouve au niveau de toutes les méthodes d'AtomicInteger.
    Par exemple pour incrementAndGet() :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
        public final int incrementAndGet() {
            for (;;) {
                int current = get();
                int next = current + 1;
                if (compareAndSet(current, next))
                    return next;
            }
        }

    1. On récupère la valeur courante (avec get()) dans une variable locale "current". C'est une opération atomique donc on n'a pas de soucis avec cela.
    2. On incrémente la valeur, dans une autre variable locale "next". On travaille sur des variables locales donc aucun soucis.
    3. On tente d'affecter la nouvelle valeur ("next"), mais uniquement si la valeur n'a pas changé entre temps (grace à compareAndSet() et notre variable locale "current").
      Si la valeur de notre AtomicInteger n'a pas changée, il sera mis à jour avec "next" et on retourne le résultat (tout s'est bien passé).
      Mais si la valeur de l'AtomicInteger a été changée (obligatoirement depuis un autre thread), compareAndSet() ne va rien faire et retourner false. Du coup on refait un tour de boucle en renouvelant notre calcul avec la nouvelle valeur...


    Cela peut paraitre curieux mais en fait c'est bien plus rapide qu'une synchronisation :
    • S'il n'y a pas de de modification entre temps, cela revient à exécuter un code non synchronisé !
    • S'il y a eu une modification, cela revient à retenter notre chance. Pour des calculs aussi simple cela va sûrement plus vite que de poser une synchronisation.



    Au passage Java 8 propose également quelque chose de similaire pour les Locks avec les StampedLock.

    a++

  18. #18
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 247
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 247
    Points : 3 394
    Points
    3 394
    Billets dans le blog
    12

    Par défaut

    En effet, le mécanisme est vraiment très curieux. Et si "count" ne vaut jamais "current" on tombe dans le boucle infini, du coup :
    • Comment "get()" est susceptible de retourner une "value" où "current" serait égal "count" ?
    • Quel est le nombre d'itération théorique maximum pour que "count" == "current", le nombre de thread qui traite "count" en même temps ?
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Mon profil Developpez | Mon profil Linkedin | Mon site : https://gokan-ekinci.appspot.com

  19. #19
    Modérateur

    Profil pro
    Inscrit en
    septembre 2004
    Messages
    11 655
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 11 655
    Points : 19 776
    Points
    19 776

    Par défaut

    Citation Envoyé par Gugelhupf Voir le message
    Comment "get()" est susceptible de retourner une "value" où "current" serait égal "count" ?
    Ben, il lit la valeur actuelle du compte et la renvoie. Techniquement ce sera jamais autre chose qu'un "current" égal à "count". La raison de tout ce bazar étant que "count" peut très bien avoir changé deux instructions plus loin.

    Citation Envoyé par Gugelhupf Voir le message
    Quel est le nombre d'itération théorique maximum pour que "count" == "current", le nombre de thread qui traite "count" en même temps ?
    Théorique maximum, c'est bel et bien l'infini. Si un autre thread passe son temps à incrémenter le compteur et que le thread en cours est bizarrement aligné par l'ordonnanceur de sorte de ne jamais, jamais faire une boucle entière avant que l'autre ne fasse la sienne, eh ben, il continuera d'essayer pour toujours et restera coincé là.

    En pratique, toutefois, quand un thread a fini de toucher un compteur il va bosser ailleurs pendant un moment, laissant les autres faire leur propre modif avant de revenir les déranger. C'est une mauvaise idée d'avoir un thread qui ne fait que toucher à un AtomicInteger utilisé par d'autres... Mais en soi, ça devrait être évident que c'est une mauvaise idée de faire un thread qui sert à rien.
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  20. #20
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 930
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 930
    Points : 22 979
    Points
    22 979
    Billets dans le blog
    1

    Par défaut

    @Gugelhupf : Attention c'est l'ancienne valeur qui est vérifiée, pas celle que l'on a calculé.
    • get() renvoit la valeur actuelle de l'AtomicInteger, que l'on stocke dans une variable locale ("current" dans l'exemple d'incrementAndGet()).
    • On fait notre calcul, que l'on stocke dans une autre variable ("next" dans l'exemple)
    • Enfin compareAndSet() n'affectera la valeur que l'on a calculer ("next") que si la valeur de l'AtomicInteger est toujours égale à "current".
      En clair si la valeur de l'AtomicInteger n'a pas été modifiée depuis la première fois qu'on y a accédé, on affecte notre résultat, sinon on recommence notre calcul car il n'est plus bon...



    Citation Envoyé par thelvin Voir le message
    Théorique maximum, c'est bel et bien l'infini. Si un autre thread passe son temps à incrémenter le compteur et que le thread en cours est bizarrement aligné par l'ordonnanceur de sorte de ne jamais, jamais faire une boucle entière avant que l'autre ne fasse la sienne, eh ben, il continuera d'essayer pour toujours et restera coincé là.
    Oui.

    Mais cela poserait également problème avec une synchronisation classique, puisqu'on serait bloqué sur l'acquisition du lock.
    Dans ce cas l'utilisation de l'AtomicXXX serait plus gourmande en CPU (boucle active) tandis que le code synchronisé serait en sommeil.
    Mais comme tu le dis il faut avoir une boucle infini qui modifie constamment la variable...

    Dans un cas "normal" même si l'AtomicXXX doit faire quelques tours de boucles il y a des chances que ce soit plus rapide qu'une synchronisation....


    a++

Discussions similaires

  1. Demande d'avis pour valider ma conception pour projet PFE
    Par xalam dans le forum Diagrammes de Classes
    Réponses: 1
    Dernier message: 29/04/2010, 03h49
  2. Réponses: 2
    Dernier message: 11/04/2010, 11h53
  3. projet client serveur : manque de fonctionnalité
    Par king_neo2001 dans le forum Réseau
    Réponses: 15
    Dernier message: 22/05/2007, 22h20
  4. Recherche un logiciel pour cartographier le code source java d'un projet
    Par L4BiN dans le forum EDI et Outils pour Java
    Réponses: 3
    Dernier message: 12/09/2006, 15h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo