Discussion :

[Pierre8r]

Bonjour,

Threads.
Peut-on appeler la méthode d'un thread depuis un autre thread sans nécessité de synchronisation ?

Ce programme est-il correct ?

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
package testthread;
 
public class TestThreadsStart {
 
	/**
         * @param args
         */
 
	private String stringCommun;
 
	public static void main(String[] args) {
		System.out.println("Program Begin");
		ThreadAAA threadAAA = new ThreadAAA();
		ThreadBBB threadBBB = new ThreadBBB(threadAAA);
		threadAAA.start();
		threadBBB.start();
		System.out.println("Program End");
	}
 
}

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
package testthread;
 
public class ThreadAAA extends Thread {
 
	@Override
	public void run() {
		incrementeConmpteur(80, "From ThreadAAA : ");
	}
 
	void incrementeConmpteur(int ctr, String strFrom) {
		for (int i = 0; i < ctr; i++) {
			System.out.println("ctr : " + ctr + "  " + strFrom + i);
		}
 
	};
}

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
package testthread;
 
public class ThreadBBB extends Thread {
 
	ThreadAAA threadAAA;
 
	public ThreadBBB(ThreadAAA threadAAA) {
		this.threadAAA = threadAAA;
	}
 
	@Override
	public void run() {
		threadAAA.incrementeConmpteur(10, "Step 1 From ThreadBBB Target 10 : ");
		threadAAA.incrementeConmpteur(17, "Step 2 From ThreadBBB Target 17 : ");
		threadAAA.incrementeConmpteur(23, "Step 3 From ThreadBBB Target 23 : ");
	}
}

[adiGuba]

Salut,



Ici il n'y a pas de problème puisque la méthode incrementeConmpteur() est thread-safe !

En effet, lorsqu'on regarde le code de cette méthode, on voit qu'elle ne manipule que trois références : ctr, strFrom et i.
Les deux premiers sont des paramètres, le dernier un paramètre local donc aucun soucis de synchronisation !


Les soucis surviennent lorsqu'on partage des références d'objets non-final, non-immuable et non-thread-safe, où une modification dans un thread peut aboutir à un comportement incorrect dans un autre...

a++

[Pierre8r]

Merci adiGuba.

Quand faut-il encapsuler un traitement dans un thread ?
Y-a-t-il d'autres circonstances, que lorsqu'on souhaite donner à un traitement une priorité différente par rapport aux autres traitements ?

Si l'on utilise des classes enveloppes autour de sockets dont les réponses sont asynchrones, faut-il isoler ce code dans un thread ?

[adiGuba]

Quand faut-il encapsuler un traitement dans un thread ?

Ben... lorsque tu veux exécuter un traitement "en parallèle"...

Y-a-t-il d'autres circonstances, que lorsqu'on souhaite donner à un traitement une priorité différente par rapport aux autres traitements ?

Ce n'est pas vraiment un question de priorité mais d'exécution en parallèle.
Si tu veux vraiment donner une plus grande priorité à un traitement tu n'as qu'à exécuter seulement ce dernier AVANT les autres...

Si l'on utilise des classes enveloppes autour de sockets dont les réponses sont asynchrones, faut-il isoler ce code dans un thread ?

Ben théoriquement les sockets asynchrones sont faite pour du mono-thread... (lire : IV-D. Comment réaliser une application réseau monothread)

Donc la réponse est la même : tu dois utiliser un second thread seulement si tu as d'autres traitements à faire en parallèle...



Note : dans une interface graphique il faut bien sûr utiliser un thread afin d'éviter de faire des traitements lourds dans l'EDT (le thread qui gère la mise à jour de l'affichage et les évenements).

a++

[Pierre8r]

Merci adiGuba.