Discussion :

[rushtakn]

Salut,

Qu'est ce qui se passe quand plusieurs objets accèdent à une methode en meme temps (methode pas focement synchronisée dans le cas où elle ne modifie que des parametres locaux par exemple) ?
Est ce que le bout de code est dupliqué et chaque appel à cette methode est finalement independant, où est ce que ça marche autrement ?

[-gma-]

Bonjour,

Ça dépend ce que tu entends par "paramètre locaux".

Chaque thread a sa propre pile (stack) dans laquelle sont conservées les variables locales et les résultats intermédiaires.
Par contre le tas (heap) est partagé par tous les threads de la JVM et il contient tous les objets.

Donc tant que tu manipules des types primitifs (ou des objets immutable comme String) en variables locales (ou paramètres) il n'y a pas de problème de synchro puisque tu es dans un espace propre au thread.
En revanche si tu as une référence locale vers un objet (ou un tableau), cette référence est bien locale mais elle pointe vers un objet du tas qui lui est partagé alors il peut y avoir des problématiques d'accès concurrents sur les attributs de cet objet. Tous les attributs de la classe courante (this) rentrent dans cette catégorie puisqu'ils sont aussi dans le tas.

[rushtakn]

Ça dépend ce que tu entends par "paramètre locaux".

Prenons l'exemple d'une methode qui fait l'addition de 2 entiers passés en parametres. J'ai plusieurs threads qui accedent simultanement à cette methode.

Je manque de notions "bas niveau" donc la question est stupide, mais qu'est ce qui fait que ça ne crash pas. Est ce qu'il y a autant de "copies" de la methode qu'il y a d'appels à cette methode ?

[hwoarang]

Dans ce cas la, tu n'utilise que des variables locales. Donc, comme précisé par gma, il n'y a pas de probleme puisque chaque thread va instancier les variables locales qu'il utilise.

Le probleme se pose si tu utilises les variables de classe (this->???). Mais dans ton cas, non donc pas de probleme...

[rushtakn]

Ok pour les variables. Mais où sont stockées les instructions de la methode ?

[thelvin]

Je manque de notions "bas niveau" donc la question est stupide, mais qu'est ce qui fait que ça ne crash pas. Est ce qu'il y a autant de "copies" de la methode qu'il y a d'appels à cette methode ?

Parce que les choses ne crashent pas pour de vagues impressionz qu'un truc ne va pas. Les choses crashent quand quelque chose provoque ce crash. Et là, rien ne peut le provoquer.

Il n'y a pas besoin de "copier la méthode." Le code d'une méthode est en lecture seule, pas moyen de le modifier pendant l'exécution. Donc tout le monde peut se le partager sans problème. Sur les OS modernes, c'est le cas de pratiquement tout ce qui est code exécutable.

Les données manipulées par la méthode, ça c'est une autre histoire.
Comme déjà dit, si ce sont des variables locales, elles sont stockées sur la pile et chaque thread a sa propre pile qu'il ne partage pas avec les autres, donc pas de problème.
Si c'est autre chose, là, il peut en effet y avoir conflit dans l'ordre des lectures et écritures. Ça ne provoque pas forcément de crash, mais ça provoque des états incohérents des données manipulées, ce qui peut être très grave (et aussi, provoquer un crash, mais ça, c'est un moindre mal comparé à des résultats incorrects.)

[rushtakn]

merci je vois mieux.

[-gma-]

Ça ne provoque pas forcément de crash, mais ça provoque des états incohérents des données manipulées, ce qui peut être très grave (et aussi, provoquer un crash, mais ça, c'est un moindre mal comparé à des résultats incorrects.)

Tout à fait, les problèmes de concurrence sont généralement intermittents ce qui les rend encore plus difficiles à résoudre, car plus difficiles à reproduire.