Discussion :

[Bluedeep]

Par contre le lock doit ralentir les traitements non ?

Tout à fait; d'où la necessité de bien réflechir aux sections que l'on lock.

En fait, il s'agit de la problématique du singleton mal implémenté.

Comprends pas ....

Du coup, plutôt que de partager une variable entre les processus légers, ne serait-il pas mieux que chaque processus ait sa variable et que les résultats soient compûtés ensuite ?

Si c'est possible, c'est ce qu'on fait; mais ce n'est pas toujours le cas.

[BenoitM]

Le but c'est que les threads soient le plus isolé possible et qu'il ne partage de l'information que quand c'est nécessaire.

[Bluedeep]

Le but c'est que les threads soient le plus isolé possible et qu'il ne partage de l'information que quand c'est nécessaire.

C'est bien pour cela qu'on a les objets de synchro et le "lock" (même si un peu grossier) fait parti de la panoplie (avec les semaphore, mutex, monitor, etc ....). Le "lock" est d'ailleurs réalisé via les méthodes de Monitor.

Pour ceux qui ont bossé avec Win32, le lock est le strict équivalent des fonctions EnterCriticalSection et LeaveCriticalSection en Win32.

[antoine.debyser]

Tout à fait; je crois que j'avais tout simplement mal lu ta réponse.

y'a pas de mal.