Donc c'est comme si l'on avait pas fait de Thread ?
Version imprimable
Exactement
;)
oui, tu ne fais qu'appeler une méthode en appelant run. start(), par contre, est une méthode native qui va créer un nouveau thread et ce nouveau thread exécutera la méthode run() ;)
Bonjour,
suite et fin de mon choix d'architecture avec les Threads.
J'ai finalement opté pour l'architecture suivante qui est aussi rapide que ce que j'avais marqué en première page, mais qui évite la redondance de code :
Code:
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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47 class Dilatation { ... public Image Execution(ImageATraiter, ImageResultat, int nbCPU) { ... switch ( nbCPU ) { case 1 : DilatationThread DT = new DilatationThread(ImageATraiter, ImageResultat, Toute l image) ; DT.run() ; DT = null ; break ; case 2 : DilatationThread DT1 = new DilatationThread(ImageATraiter, ImageResultat, Moitié inférieure de l image) ; DT1.Start() ; DilatationThread DT2 = new DilatationThread(ImageATraiter, ImageResultat, Moitié supérieure de l image) ; DT2.Start() ; try { DT1.join() ; DT2.join() ; } catch (...) {...} DT1 = null ; DT2 = null ; break ; default : // Non géré... } ... } private DilatationThread extends Thread { ... public DilatationThread(ImageATraiter, ImageResultat, Bornes) { this.... } public void run() { // Mon traitement d'image en fonction des bornes. } } }
Ben ça marche super bien et c'est pratique à utiliser.
les assignation de null sont inutiles ;)
Je pensais que ça aidait un peu le ramasse-miettes :aie:
en effet ça peut, mais en l'occurence ce sont des variables internes, et dès qu'on sort du bloc dans lequel elles sont utilisées, les références sont perdues et le GC fera son boulot
ça aide surtout lorsque ce sont des champs de classe. c'est presque jamais utile pour des variables locales
;)
Ok merci...
Bon on dira alors que : c'est une bonne habitude qui ne coûte rien et peut aider :D
en fait si, ca coute: une affectation :D