2009-04-25 4 views
4

J'ai rempli plusieurs listes <> avec des valeurs par défaut, les ai collées dans une structure puis j'ai passé la structure dans plusieurs threads. Chaque thread a une plage différente donc le thread 1 accèderait à la liste [0 à 199] le thread 2 accèderait à [200 - 400] etc. Aurais-je besoin d'un verrou? et quand en ai-je besoin? Je peux accéder à la liste avec mes multiples threads sans utiliser de verrou. Mais si mon thread principal veut lire les données de la liste (jamais écrire) ai-je besoin d'un verrou pour cela? Je suis sûr que je ne sais pas mais je voudrais demander avant la mise en œuvre.Ai-je besoin d'un verrou sur une liste? C#

-Edit-

Merci les gars, vous avez répondu à ma question. (J'accepterai un plus tard tant que quelqu'un ne réfutera pas les réponses actuelles)

Répondre

2

Si vous êtes absolument sûr de ne pas modifier les listes actuelles (ajouter des articles, supprimer des articles, etc.), vous n'avez pas besoin de verrou.

8

Si vous ne modifiez pas la collection, vous n'aurez pas besoin de verrouillage du tout. Si vous souhaitez modifier la collection avec l'un des threads, vous pouvez regarder le ReaderWriterLock.

Le commentaire de Peter est remarquable. Comme indiqué également par le lien MSDN ci-dessus, vous devriez envisager d'utiliser la classe ReaderWriterLockSlim si vous utilisez .NET 3.5. L'idée est la même, néanmoins.

+2

Ou le nouveau et amélioré ReaderWriterLockSlim http://msdn.microsoft.com/en-us/library /system.threading.readerwriterlockslim.aspx –

+1

Assurez-vous de lancer des tests si vous ne maintenez pas les verrous assez longtemps pour provoquer beaucoup de conflits, un verrou standard peut être plus rapide. Si vous n'obtenez pratiquement aucun conflit, un SpinLock (nouveau dans PFX/.NET 4.0) peut être une option encore meilleure dans le futur. –

+0

@Jonathan, absolument. Sur des plates-formes massivement parallèles, les SpinLocks fonctionnent presque toujours mieux –

2

Vous n'avez pas besoin de verrou si vous n'écrivez pas. Cependant, si vous écrivez dans les autres threads, vous devriez avoir un verrou. Même si ces threads n'accèdent qu'à des plages spécifiques, si vous ajoutez des nœuds à la liste, cela peut provoquer des problèmes. Si vous ne modifiez pas la structure de la liste mais que vous changez seulement celle-ci dans les nœuds, je ne pense pas qu'il y ait un problème.

+0

Ce n'est pas vrai. Un autre thread pourrait supprimer ou modifier votre collection pendant que vous le lisez –

+0

Je pense que Megacan signifiait, si les threads ne définissaient que des valeurs dans la liste, comme dans la liste [i] = value, ET ce sont toujours des index différents pour différents threads changements en cours, il devrait être thread-safe sans verrous. Cela ne veut toutefois pas dire que c'est - je ne connais pas suffisamment les internes de List <> pour dire que c'est sûr. Je pense que dans ce cas, un tableau devrait être utilisé - et un tableau est thread-safe dans ce contexte. – configurator

+0

Une liste dont la taille ne change pas est thread-safe dans l'implémentation actuelle (c'est un tableau interne). Si vous modifiez la taille, ce n'est pas sûr pour les threads (car il se peut que ce tableau doive être réaffecté pour tout ajout). –

0

Avez-vous envisagé d'utiliser des tableaux? Un tableau est thread-safe tant que vous n'accédez pas au même index dans deux threads. En outre, il est plus rapide si vous ne changez pas la taille.

1

Dans votre objet struct, je marquerait au moins la variable ReadOnly et peut-être la nouvelle ReadOnlyCollection

public struct MyStruct 
{ 
    private readonly ReadOnlyCollection<int> _myInts; 

    public MyStruct(ReadOnlyCollection<int> ints) 
    { 
     _myInts = ints; 
    } 
} 
Questions connexes