Question sur la sécurité des champs d'instance et des origines de thread

Question

En C#, un champ de classe signifie que chaque thread a sa propre instance de cet objet.

E.g. le thread 1 aura sa propre instance de l'objet a, tout comme l'objet b.

Donc 2 utilisateurs d'une application web, sur différents PC, devraient accéder à un champ d'instance (Dites une collection) sous différents threads, non? Cela me fait poser la question, pourquoi aurais-je besoin d'écrire du code pour synchroniser la collection? Si la collection est basée sur une instance et non sur un état partagé. Est-ce seulement dans le fait que je peux avoir un autre thread essayer de lire la collection que je modifie son état. Je dis "Est-ce" parce que c'est seulement un cas possible à travers le code que j'écris réellement? Par exemple. générer un thread pour lire une collection non synchronisée et utiliser le thread d'origine pour écrire dans la collection. Ou y a-t-il d'autres trucs?

Je l'ai mis dans la section débutant car cela semble être une question fondamentale.

Merci

Answer 1

En C#, une classe par défaut ne dispose pas de son propre instance de chaque objet.

Les instances de classe et les threads sont deux constructions séparées (sauf si un membre est marqué [ThreadStatic] ou une autre exception). Si vous créez des instances, puis exécutez un thread séparé, il fonctionnera sur les mêmes instances (sauf si le thread séparé crée ses propres instances d'objets).

Étant donné que les threads fonctionneront normalement sur les mêmes instances (afin de partager des données et un état), vous devez les synchroniser de manière appropriée.

Si les threads ne partagent jamais l'état ou les instances d'objets, vous n'avez pas besoin de vous soucier de la synchronisation. Cependant, cela est rare en pratique: les threads travaillent généralement sur un type de données partagées. Si chaque thread engendré crée ses propres objets et qu'aucun autre thread ne leur parle, vous pouvez ignorer la synchronisation.