Discussion :

[®om]

Est-ce que ce genre de truc a besoin d'être synchronisé?

Code :

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

1
2
3
4
5
6
7
8
9
private String s;
 
public void setString(String s) {
    this.s = s;
}
 
public void getString() {
    return s;
}

Est-ce que si un Thread fait setString alors qu'un autre fait getString, cela va lever une exception?
Parce que "this.s = s" peut être vu comme "atomique" (en tout cas ne dérangeant ps le get)

?

Merci de votre réponse

[spekal]

OUI, cela a besoin d'être synchronisé si plusieurs threads risquent d'écrire et de lire à la fois. NON, cela ne peut pas être vu comme une opération atomique.

[the-gtm]

this.s = s pas atomique ? Ca m'étonne ... this.s a soit l'ancienne valeur, soit la nouvelle non ?
Ce serait quoi l'état intermédiaire ? Moitié this.s / moitié s ou bien null ??

[adiGuba]

Salut,


Je pense également que les affectations de références sont des opérations atomiques...
Il faudrait vérifier dans les spécification pour en être sûr... Mais la classe AtomicReference se contente des méthodes suivantes :

Code :

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

1
2
3
4
5
6
7
8
 
    public final V get() {
        return value;
    }
 
    public final void set(V newValue) {
        value = newValue;
    }

Maintenant il faut voir le reste de ta classe.
Par exemple si tu as une méthode du style :

Code :

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

1
2
3
4
5
public void method() {
    if (this.s != null && !this.s.equals("")) {
        doSomething(this.s);
    }
}

Là tu peux avoir des problèmes car la valeur de this.s peut être modifié entre les tests et l'appel à la méthode il faudrait synchronizé le set() et la method()...

Toutefois dans ce cas là je pense que tu peux complètement te passer de synchronisation avec un code du style :

Code :

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

1
2
3
4
5
6
7
public void method() {
    String val = this.s;
 
    if (val != null && !val.equals("")) {
        doSomething(val);
    }
}

Si la valeur de this.s change pendant le déroulement de la méthode cela n'aura aucun impact sur ta méthode qui utilisera toujours l'ancienne valeur...

a++

[spekal]

Ah ! Je vois qu'il faut que je me justifie ! Bon...

this.m = chose n'est pas atomique à ma connaissance, parce que cette opération est en fait constituée de deux opérations : une opération d'utilisation, ou de lecture de chose, dite use dans la littérature javasienne et une opération d'assignement, dite, cela tombe bien assign dans la littérature javasienne.

Voir tout le Threads and Locks de la VM Spec, particulièrement le 8.1 Terminology and Framework, le 8.10 Example: Possible Swap.

Il me semble qu'on le voit aussi en analysant le byte code ; sur cette classe très simple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public class AssignUse
{
  private String s;
  private String t;
 
  public AssignUse()
  {
    s = t;
  }  
}

On obtient par javap :

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
 
classes> javap -c goodies.AssignUse
Compiled from "AssignUse.java"
public class AssignUse extends java.lang.Object{
public AssignUse();
  Code:
   0:   aload_0
   1:   invokespecial   #1; //Method java/lang/Object."<init>":()V
   4:   aload_0
   5:   aload_0
   6:   getfield        #2; //Field t:Ljava/lang/String;
   9:   putfield        #3; //Field s:Ljava/lang/String;
   12:  return
 
}

On voit très bien ligne 6 getfield, opération de chargement, puis ligne 9 putfield, opération d'assignement, et donc la commutation de thread peut très bien survenir entre les deux.

D'autres réserves, chers amis ?

[®om]

On voit très bien ligne 6 getfield, opération de chargement, puis ligne 9 putfield, opération d'assignement, et donc la commutation de thread peut très bien survenir entre les deux.

D'autres réserves, chers amis ?

Certes, mais, même dans le cas où la commutation intervient entre les deux, ça change quoi dans le cas très particulier où on ne fait qu'un getString()?

[spekal]

J'en sais rien

À la question : l'assignement (niveau code java, pas bytecode) est-il atomique? la réponse est non, c'est tout ce que je peux dire.

Après, on se permet certains risques dans la programmation multithread, puisque dans la programmation multithread on est souvent obligé de composer avec des tolérances. On se dit : Ici, le thread lira une variable qui risque une fois sur 1.000 de ne plus être correcte depuis un pouillème de milliardème de seconde... c'est peut être pas fondamental.

Mais méfions-nous que ici c'est un cas d'école, et que la réalité à vite fait d'avoir plus d'imagination que nous. C'est pour ça que j'ai préféré répondre non un peu brutalement à la question. Une des spécificités de la programmation multi-thread est que les approximations partent en vacances toujours juste pile le jour de la recette. Donc...

[adiGuba]

D'autres réserves, chers amis ?

Non c'est très clair

Par contre si l'opération d'affectation n'est pas "atomique", je ne pense pas que le couple get/set tel qu'il est présenté pose des pbolèmes lorsqu'il n'est pas synchronisé !

Après tout l'opération "getfield" concerne le paramètre et non pas l'attribut de la classe.
Donc si l'affectation n'est pas atomique, l'opération "setfield" l'est, et comme c'est la seule opération qui utilise notre champs (si je ne me trompe pas), cela ne gène en rien le coté multithread. Ainsi il n'est y a pas forcément besoin de synchroniser la méthode...

Cf cette article anglais qui en parle :
http://www.javaworld.com/jw-09-1998/jw-09-threads.html


Perso c'est le genre de chose que j'évite de synchronisé quand c'est possible, afin d'éviter de me retrouver bloqué par un simple set() lorsqu'un autre thread a posé le verrou pour une tâche plus longue...

a++