My.Settings vraiment threadSafe ?

Bonjour,

Dans la procédure éxecutée par les threads j'ai placé ça :

My.Settings.TestInteger += 1

TestInteger est un Integer qui vaut 0 au départ.

Je lance 10 Threads et à la fin, TestInteger vaut toujours moins que le nombre de thread.

j'en conclue que, grosso modo, deux Threads ont lu la valeur (copié ?) par exemple "1" un des deux fini et passe le TestInteger à 2 et l'autre fait de même, sans se rendre compte qu'entre temps la valeur a bougée.
Il (re)mets donc aussi TestInteger à 2.

Je ne cherche pas de solution au problème, je la connais (bloc Sync Lock etc) mais MSDN Indique que my.Settings est Thread Safe en plus la prop Synchronized de My.Settings et bien à True. Et j'ai le meme pb avec un instance de My.Settings obtenue avec la méthode "Synchronized".

Que veut donc dire thread safe ici si alors qu'un thread manipule l'objet un autre peut aussi le faire. Juste que cela ne léve pas d'exception Ex DeadLock.

Si qq a une tite explication... ;)

Je sais pas trop pour l'histoire du Thread safe de cette classe. Cependant, quand on fait

Code:

---

My.Settings.TestInteger += 1

---

il se pourrai que le compilateur l'interprète comme

Code:

---

My.Settings.TestInteger = My.Settings.TestInteger + 1

---

Et dans ce cas alors le problème deviens possible même si Settings est Thread Safe. Il faudrait locker l'objet Settings ou alors faire un truc qui implémente une fonction "Inc"...

ou synclock

Oui c'est sur qu'il va bosser avec des copies.
La mention Thread Safe garantirait ainsi une manipulation sans exception mais par contre le résultat n'est pas garanti. lol :?

Oui je connais le Sync Lock, mais ce n'est pas la solution que je chercher c'est l'explication. C'est clair qu'avec un SyncLock ya plus de pb.

Au moins cela semble sous entendre que pour des accés en lecture seule cela ne pose pas de pb.

t'as essayé dans les 2 modes debug et release pour voir si ca fait pareil ?

Non mais bon je pense que si ça doit encore être pire... :yaisse2: