Discussion :

[ToTo13]

Bonjour,

j'essaye de faire du multithreading en traitement d'images.
J'utilise pour l'instant ce type de code :

Code java :

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
21
22
23
24
25
26
 
public Image Dilatation(Image ImageATraiter)
	{
	final int var1 ;
	...
	Thread T1 = new Thread()
		{
		public void run()
			{
			//Traitement de la moitié de l'image... en utilisant var1
			}
		}
 
	Thread T2 = new Thread()
		{
		public void run()
			{
			//Traitement de l'autre moitié de l'image... en utilisant var2
			}
		}
 
	T1.join() ;
	T2.join() ;
	...
	return ImageResultat ;
	}

Pour que mes deux threads puissent utiliser var1, je dois la déclarer en dehors ET de mettre 'final'. Ceci me chagrine un peu car j'aurai par la suite des variables dont je souhaiterai modifier les valeurs par les threads.

Je sais que sinon je pourrais déclarer une fonction qui étends la classe Thread, à laquelle je passerai les bornes de traitement (les deux moitiés de mon image) et qu'il me suffirait d'appeler deux fois. Mais je préférerai éviter cela.

Comment puis résoudre ce problème ?

Merci par avance

[Deaf]

Bonjour,

Tu peux t'en sortir en déclarant tes variables en membre de ta classe plutôt qu'en variable locale.
Si c'est ce que tu fais, documente-toi sur le mot-clé volatile, il pourrait t'être utile...

[ToTo13]

Si c'est ce que tu fais, documente-toi sur le mot-clé volatile, il pourrait t'être utile...

C'est fait, merci... mais ce mot clé semble très fortement déconseillé et surtout pas géré par toutes les JVMs.

[Deaf]

Si tu décides de t'en passer, soit tu acceptes le fait de pourvoir lire une valeur obsolète, soit tu mets en place un système qui te garantit la synchronisation.

Le tout est de bien connaître les risques.

[professeur shadoko]

C'est fait, merci... mais ce mot clé semble très fortement déconseillé et surtout pas géré par toutes les JVMs.

ah bon?
la spec de 1.5 a mis au point la sémantique de volatile (qui n'était pas claire avant). Elle concerne deux aspects:
- la validité d'une donnée au regard des copies qu'un thread fait de la mémoire principale
- l'interdiction faite de réordonnancer des instructions élémentaires au travers de la "barrière" ainsi créée.

Il y aurait des JVM (post 1.5) non conformes aux specs?
pourquoi fortement déconseillé? il me semble que ça a un sens suffisament ciblé (bien sûr si c'est pas ça qu'on cherche .... par exemple on n'a pas d'atomicité -même sur une opération comme l'incrémentation-)

[tchize_]

dans ton cas, je recommanderais plutot de réorganiser un peu le code pour éviter ces problèmes.

1) Faire des tes annonymous inner class des simples inner classe avec un nom, ainsi tu pourra leur mettre un constructeur qui recois les données.

2) Pour toutes les données que devront s'échanger les Thread en question, mettre ces donnée dans une classe Data, avec éventuellement le mot clé volatile devant comme déjà expliqué, et passer cette instance de Data aux deux Thread.

Ca ressemblreais à ça.

Code :

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

1
2
3
4
5
Public class ThreadCalcul extends Thread{
    // ....
    public ThreadCalcul(Data data) {.....}
    // ....
}

Code :

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

1
2
3
public class Date {
     public volatile int uneDonnee;
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public Image Dilatation(Image ImageATraiter){
    Data data = new Data();
    data.uneDonnee = ....;
    Thread t1 = new ThreadCalcul(data);
    Thread t2 = new ThreadCalcul(data);
    t1.start();
    t2.start();
    t1.join();
    t2.join();
}

[ToTo13]

Merci, c'est justement ce que je suis en train de tester ;-)

[ToTo13]

Bonjour,

mon dernière réponse dans cette discussion montre le choix d'architecture que j'ai choisi, car ça réponds à tous les problèmes que j'avais.

Merci...