IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Concurrence et multi-thread Java Discussion :

[Language]Immutable & Thread-Safe


Sujet :

Concurrence et multi-thread Java

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2003
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2003
    Messages : 16
    Points : 10
    Points
    10
    Par défaut [Language]Immutable & Thread-Safe
    Bonsoir,

    Voilà une question me tarraude concernant les objets immutables. Un objet immutable dans une application single thread est-il obligatoirement Thread-safe Immutable (non modifiables a partir d'un autre Thread)?

    Et dans ce cas, qu'est-il possible de faire pour la rendre telle quelle ? Mis à part rendre la classe final pour éviter tout héritage donc toute redéfinition, ainsi que les champs private et final, je ne vois pas ce que je faire d'autre.

    De plus, certaines classes du package accèdent à des champs qui sont env visibilité package. Je pensais mettre ces champs en private et final (car ils sont uniquement lus) et synchroniser les accesseurs de ces champs.

    Enfin, j'ai remarqué qu'il y avait un souci quand on essaye d'affecter une valeur à un champ final dans le constructeur suivant différents branchements. Je m'explique :

    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
     
     
     
    public class Test {
     
        final private int field;
     
        public Test(int testValue) {
            this.field = 1;
     
            if(testValue == 0)
                this.field = 0;        
        }
     
    }
    J'ai un warning dans eclipse qui m'indique que ce champ a pu être initialisé avant (normal me direz-vous). Y a t-il un moyen de contourner ce problème ?

    Si quelqu'un a d'autres suggestions concernant le fait que la classe soit immutable en single-thread et pas en multithread je suis preneur !

    Merci d'avance !

  2. #2
    Nouveau membre du Club
    Inscrit en
    Décembre 2005
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 28
    Points : 30
    Points
    30
    Par défaut
    On ne peut assigner une valeur à une variable final qu'une seule fois, si tu veux que ton code marche il faut plutot faire comme ça :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    public class Test { 
     
        final private int field; 
     
        public Test(int testValue) { 
            if(testValue == 0) 
                this.field = 0;  
             else {
                this.field = 1;
             }
        } 
    }

    Ensuite une classe immutable signifie qu'aucun de ses champs ne peuvent être modifiés aprés sa création donc que ce soit en single ou en multi thread ça ne fait aucune différence.

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2003
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2003
    Messages : 16
    Points : 10
    Points
    10
    Par défaut
    Merci pour ta réponse :-).

    Je me posais la question car j'ai vu quelques parts (dans la bug database de sun il me semble) que certains objets dits immutables ne l'étaient pas quand il s'agissait d'application multithreadée.

    En effet, en construisant une instance de l'objet dans un Thread et en passant la référence vers cet objet dans un autre Thread il était alors possible de le modifier alors qu'à la base il est immutable (il me semble que c'était la classe BigInteger de mémoire).

    D'où mon interrogation ...

  4. #4
    Nouveau membre du Club
    Inscrit en
    Décembre 2005
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : Décembre 2005
    Messages : 28
    Points : 30
    Points
    30
    Par défaut
    Après si y'a un bug c'est autre chose... mais bon si on se rapporte à la définition de base d'un objet immutable, le multithread ni change absolument rien, reste à voir si l'objet concerné auquel on associe le caractère immutable l'est réellement.

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    Février 2003
    Messages
    16
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2003
    Messages : 16
    Points : 10
    Points
    10
    Par défaut
    Ok c'est bien ce que je pensais aussi mais bon j'avais quelques doutes quand meme Merci à toi

Discussions similaires

  1. [RCP] Treeviewer non thread-safe ?
    Par Guildux dans le forum Eclipse Platform
    Réponses: 4
    Dernier message: 09/01/2007, 13h00
  2. [VB.net 2005] Thread safe call
    Par WriteLN dans le forum Windows Forms
    Réponses: 5
    Dernier message: 19/06/2006, 12h36
  3. fonction de stdio.h thread safe ??
    Par boolzor dans le forum POSIX
    Réponses: 3
    Dernier message: 30/04/2006, 20h03
  4. Code "Thread Safe" ?
    Par Neitsa dans le forum C++
    Réponses: 3
    Dernier message: 23/12/2005, 14h33
  5. [MFC] CMAP non thread safe ?
    Par fmarot dans le forum MFC
    Réponses: 5
    Dernier message: 04/10/2005, 13h21

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