Discussion :

[behess]

Le singleton est-il compatible avec le multithreading ?

Le fait que l'instance du singleton soit partageable entre plusieurs thread fait que ses données peuvent être modifiées par plusieurs threads simultanément...

En fait j'imagine que cette question ramène à toute classe qui met à disposition des données directement ou indirectement statiques (indirectement : ici une instance est accessible statiquement).

Habituellement on doit protéger les données qui peuvent être modifiées par plusieurs threads.

Doit-on alors prévoir pour tout singleton une protection similaire afin d'être "MultithreadSafe" ?

[Invité]

Bonjour,
pour protéger ton singleton tu peut lui associer un attribut booléen :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
classe singleton {
  privé booleen verou;
}

Suivant la valeur de cet attribut tu permet l'accès au singleton ou non.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
methode get_instance(){
  ....
  SI(this.verou){
    insérer demande dans liste d'attente;
  }
  SINON{
    retourner objet
  }
}

methode set_verrou(valeur){
  this.verou = valeur;
}

[behess]

ta reponse est donc oui ? pour la methode je prefererais utiliser les outils de synchronisation du langage !

[behess]

Bonjour,
pour protéger ton singleton tu peut lui associer un attribut booléen :

[...]

Voici une implémentation en C# de cette idée ; ça ajoute juste une méthode de release de l'instance, ça pourrait peut-être aller.

Le soucis principal c'est que si l'utilisateur du singleton fait simplement instanceRef=null ou même s'il n'appelle pas la méthode Release, le singleton reste verrouillé... il faut donc bien faire attention.

J'aurai aimé quelque chose de plus systématique... mais cela semble impossible !

[ego]

Le singleton est-il compatible avec le multithreading ?

Le fait que l'instance du singleton soit partageable entre plusieurs thread fait que ses données peuvent être modifiées par plusieurs threads simultanément...

En fait j'imagine que cette question ramène à toute classe qui met à disposition des données directement ou indirectement statiques (indirectement : ici une instance est accessible statiquement).

Habituellement on doit protéger les données qui peuvent être modifiées par plusieurs threads.

Doit-on alors prévoir pour tout singleton une protection similaire afin d'être "MultithreadSafe" ?

2 autres solutions "mieux"...je pense :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public Class MySingleton {
  private static MySingleton instance;

  static {
      instance = new MySingleton ();
  }

  public static MySingleton getInstance() { return instance; }
}

L'autre solution est d'utiliser Spring !

[behess]

Oui c'est une solution classique pour un singleton.

Mais ce que je recherche c'est à bloquer cet appel à getInstance() tant qu'un autre thread UTILISE cette même instance.

C'est à dire tant qu'une référence à cette instance existe en dehors du Singleton.

J'ai pensé aux références faibles mais je ne vois pas trop comment faire, ça à l'air ardu.

[Antoine_935]

2 autres solutions "mieux"...je pense :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
public Class MySingleton {
  private static MySingleton instance;

  static {
      instance = new MySingleton ();
  }

  public static MySingleton getInstance() { return instance; }
}

Ce qui est dommage avec cette solution, c'est qu'on perd le lazy instantiation.

Personnellement, je préfère cette méthode:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public class Singleton {
    private static Singleton instance = null;

    public static synchronized Singleton getInstance() {
        if(instance == null)
            instance = new Singleton();
        
        return instance;
    }
}

On pourrait me rétorquer qu'on perd des performances si deux élements veulent l'obtenir en même temps, mais... sincèrement, la perte n'est pas extraordinaire.

Après, bien entendu, il est important de synchroniser les accès aux méthodes et attributs de ce singleton. Mais oui, le singleton peut être utilisé en multithread.
Si tu tiens absolument à bloquer l'objet tant qu'il n'est pas relaché, tu peux rajouter une méthode getLock dessus, qui retournerait un ReentrantLock assigné à cette instance. Tu peux alors locker l'instance et la relacher quand tu n'en as plus besoin. Mais là tu risques de perdre du temps à l'exécution.
Il vaut mieux synchroniser seulement ce qui en a besoin.

[behess]

Oui en fait c'est stupide, autant synchroniser toutes les méthodes d'instance... c'est carrément plus simple ! Mdr.

Que je suis con parfois.

[wiztricks]

Bonsoir
Une autre solution pour éviter les pbs de synchro d'appel a get_instance peut être de créer le singleton avant le lancement des threads applicatives.
- W

[behess]

ça aussi c'est pas con...

[Antoine_935]

Ce qui est dommage avec cette solution, c'est qu'on perd le lazy instantiation.

Vous souvenez vous de cette réponse que j'ai posté plus haut ?
Eh bien, après un des cours d'ajourd'hui, je réalise que je me suis planté, en partie du moins. La suite devrait être sufisamment explicite.

Class: Main.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
public class Main {
    public static void main(String[] args) {
        System.out.println("Entered main function");
        Loading.getInstance();
    }
}

Class: Loading.java

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
public class Loading {
    private static Loading instance;

    static {
        System.out.println("Now creating the instance");
        instance = new Loading();
    }

    public static Loading getInstance() {
        return instance;
    }
}

Resultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Entered main function
Now creating the instance

Cela est du au fait que Java fait lui-même de la lazy instantiation pour les classes. Loading ne sera pas chargé avant qu'on n'en ait besoin.

Autrement dit, si la seule méthode statique de Loading est getInstance, alors on peut se servir du clinit, tout en conservant le côté lazy.