Discussion :

[philippe13]

Bonjour,

Je souhaiterais savoir quand un singleton qui est partagé par plusieurs thread est ce que ses méthodes doivent être synchronized ?

merci d'avance.

[adiGuba]

Salut,


Les méthodes doivent être thread-safe, c'est à dire qu'elles doivent pourvoir être exécuté depuis plusieurs threads sans que cela ne pose de problème.

La synchronisation n'est qu'un des moyens permettant cela, mais ce n'est pas une obligation puisqu'il y a un grand nombre de manière de rendre une méthode thread-safe...

a++

[djo.mos]

Salut,

puisqu'il y a un grand nombre de manière de rendre une méthode thread-safe..

Dont le plus simple est de ne pas accéder en écriture (parfois même en lecture) au champs de classe. Si une méthode n'utilise que des variables locales, elle devrait être thread-safe (devrait mais pas est, car tu peux utiliser un objet non thread-safe dans cette méthode )

[philippe13]

ok merci beaucoup pour ces précisions. elles sont très claires.
Mais j'ai du mal à l'appliquer sur mon problème.

J'ai une class extends thread qui a pour run :

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
public void run() 
        {
            try{
                while(!Thread.currentThread().isInterrupted() && !stop)
               {
                    while(!EnumCommande.isEmpty())
                    {
                        nbEssai = 0;
                        while(!envoieCommande(EnumCommande.get(0).toString()) && nbEssai<3)
                        {nbEssai++;}
                        EnumCommande.remove(0);
                    }
                    Thread.currentThread().sleep(1000);
               }
            }
            catch(InterruptedException e){e.printStackTrace();}
 
        }

et une methode public addCommande :

Code :

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

1
2
3
4
public void addCommande(String commande)
        {
            EnumCommande.add(commande);
        }

De plus j'ai un "serveur" qui dispatch des actions sur les thread.

Code :

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

1
2
3
4
5
commande(string commande, int numThread)
{
      if(numThread==1){thread1.addCommande(commande);}
      if(numThread==2){thread1.addCommande(commande);}
}

Ce "serveur" est lui même dispatché sur plusieurs autres thread (threadClient)
si deux client appelle serveur.commande(blabla,1)
comment cela se passe ?
En fait je pensais que le fait de mettre toutes les commandes dans une list et de traiter ultérieurement me permettais d'éviter synchronized.

[philippe13]

Bonjour,

Bon je crois que je me suis embrouillé l'esprit pour rien....

J'ai toute de même une dernière question :
Est ce l'ordre des demandes d'accès des thread à une méthode synchronized est respectée ?
Exemple :
thread 1 est dans la methode A
thread 2 demande l'accès puis thread 3 demande l'accès. L'accès est refusé pour tous les deux.
Lors du déblocage est ce que l'on est assuré que thread 2 exécutera en premier la methode A et pas thread 3 ?

Merci d'avance.
bonne journée

[ndp]

hello,

on parle de fairness/unfairness. La dessus, je ne suis pas sur, mais il me semble qu'il n'y a aucune garantie la dessus.

Il faut savoir aussi qu'une politique juste (fairness) a un cout, puisque tout le monde va attendre, que le premier se reveille, soit restaure, prenne le verrou, fasse son traitement le relache...

[philippe13]

bonjour,

j'ai fais quelques tests et ça semble plutôt être farness. Mais bon avec les threads.... Je vais essayer de trouver une confirmation littéraire.

merci

[elmor]

java.util.concurrent.locks.ReentrantLock

Cette classe accepte en paramètre le champ fair

Par contre, le fait de vouloir délocker tout le monde dans le même ordre n'est pas sans conséquence et entraine des pertes de performances par rapport à un lock classique.

Je te conseille donc de voir s'il y a pas moyen de se priver de cette option.

[philippe13]

effectivement le plus simple est de revoir l'architecture.

Merci à tous et bonne journée