Discussion :

[livenono]

bonjour

j'ai une classe destinée à être appelée par plusieurs threads.

Jusqu'à présent, une méthode appelée uniquement par le constructeur mettait également en oeuvre les pré requis de la stratégie de synchronisation retenue (read write lock sur une map partagée).

Sommes nous d'accord que cela est inutile ?

Iriez vous jusqu'à enlever ce bout de code ?

merci d'avance
nono

[professeur shadoko]

en fait un objet n'a pas besoin d'accès "synchronized" tant qu'il n'est pas accessible.
En principe cela explique pourquoi un constructeur n'est pas "synchronized": l'objet est en cours de construction et sa référence ne doit pas être connue d'autres threads que celui qui est en train de le créer....
Sauf que .... si jamais pendant l'exécution du code du constructeur la référence "this" est passée à d'autres données externes (par ex. rattachement à un arbre) là il y a danger.... (genre d'erreur: dans un constructeur d'un composant graphique on rattache le composant courant en cours de création à d'autres composants ...)... il peut y avoir encore d'autres cas bien tordus

[livenono]

qu'en conclure donc ?

qu'il faut tout de même synchroniser "au cas où" ? => je parle essentiellement de quelle bonne pratique à recommander

pour ma part, ne pas faire appel à des méthodes surchargeables dans le constructeur me semble un BA BA. Aussi, j'aurai tendance à dire qu'on peut zapper la synchronization dans les constructeurs...

[adiGuba]

Salut,

qu'il faut tout de même synchroniser "au cas où" ? => je parle essentiellement de quelle bonne pratique à recommander

Impossible de dire cela sans voir ton code, même si en règle général les constructeurs n'utilise pas de ressources partagées...

a++

[livenono]

Salut,



Impossible de dire cela sans voir ton code, même si en règle général les constructeurs n'utilise pas de ressources partagées...

a++

hum, de quoi as tu besoin exactement ?

le code en question effectue une lecture complète d'un fichier de données afin de mettre les enregistrements s'y trouvant en mémoire (via une Map location<->enregistrement) => il fait quelques lignes..

ceci dit, pour l'essentiel, il n'appelle que des méthodes privées. Dur donc à priori de laisser échapper this qq part...

[adiGuba]

Ben que ce soit un constructeur ou une méthode, il faut vérifier la portée de tous les éléments qu'il/elle manipule (et pas seulement this) afin de s'assurer qu'ils ne peuvent pas être utilisé autre part simultanément.


Sans voir le code source c'est difficile de le dire...

a++