Les collections introduites dans le .NET Framework 1.0 se trouvent dans l’espace de noms System.Collections. Ces collections, y compris les couramment utilisées ArrayList et Hashtable, offrent une certaine sécurité de thread via la propriété Synchronized, qui renvoie un wrapper thread-safe lié à la collection. L’enveloppe fonctionne en verrouillant l’ensemble complet à chaque opération d’ajout ou de suppression. Par conséquent, chaque thread tentant d’accéder à la collection doit attendre son tour pour acquérir le verrou. Cela n’est pas évolutif et entraînera une dégradation significative des performances pour les grandes collections. De plus, ce modèle n’empêche pas complètement la contention. Pour plus d’informations, voir la page suivante sur le site MSDN : Synchronisation dans les collections génériques
La classe de collection introduite dans le .NET Framework 2.0 se trouve dans l’espace de noms System.Collections.Generic. Ces classes de collection incluent <T>Liste, Dictionnaire< TKey, TValue> etc. Ces classes offrent une sécurité et des performances de type supérieures à celles de .NET Framework 1.0. Cependant, la classe de collection .NET Framework 2.0 ne fournit aucune synchronisation de thread ; Lors de l’ajout ou de la suppression d’éléments sur plusieurs threads simultanément, le code utilisateur doit fournir toute la synchronisation.
Nous vous recommandons d’utiliser des classes de collection concurrentes dans .NET Framework 4 car elles offrent non seulement la sécurité des types des classes de collection .NET Framework 2.0, mais aussi une sécurité des threads plus efficace et complète que la sécurité des threads fournie par la collection .NET Framework 1.0.
Certains types de collections concurrentes utilisent des mécanismes de synchronisation légers tels que SpinLock, SpinWait, SemaphoreSlim et CountdownEvent, qui sont nouveaux dans le .NET Framework 4. Typiquement, les types de synchronisation ci-dessus utilisent une « tournée active » pendant une courte période avant de placer le thread en état d’attente réelle. Si le temps d’attente est censé être très court, le spin consommera beaucoup moins de ressources de calcul que l’attente, ce qui implique des conversions de noyau consommant beaucoup de ressources. Pour les classes de collection qui utilisent la rotation, cette efficacité signifie que plusieurs threads peuvent ajouter et retirer des éléments à un rythme très rapide. Pour plus d’informations sur la limitation et le blocage, voir SpinLock et SpinWait. Les classes ConcurrentQueue<T> et ConcurrentStack<T> n’utilisent pas du tout de verrous. Ils s’appuient plutôt sur les opérations Interlocked pour la sécurité des fils.
illustrer
Parce que les classes de collection concurrentes supportent ICollection, elles fournissent des implémentations pour les propriétés IsSynchronized et SyncRoot, même si elles ne sont pas liées. IsSynchronized renvoie toujours faux, tandis que SyncRoot est toujours nul (rien dans Visual Basic).
Le tableau suivant liste les types de collections dans l’espace de noms System.Collections.Concurrent.
type | description | BlockingCollection<T> | Fournit<T> tout type de limitation et de blocage pour la mise en œuvre d’IProducerConsumerCollection. Pour plus d’informations, voir Aperçu de BlockingCollection. | ConcurrentDictionary<TKey, TValue> | Key/value est une implémentation sécurisée du dictionnaire en thread. | ConcurrentQueue<T> | Implémentation de la sécurité des threads des files d’attente FIFO (premier entré, premier sorti). | ConcurrentStack<T> | Implémentation sécurisée des stacks LIFO (last-in, first-out). | ConcurrentBag<T> | Implémentation sécurisée en thread d’une collection d’éléments hors ordre. | IProducerConsumerCollection<T> | les types doivent être implémentés dansBlockingCollectionInterfaces utilisées dans le
|
|
Publié sur 06/06/2017 17:13:53
|
|
|
Publié sur 08/11/2017 15:24:45
|
Propriétaire|
Publié sur 08/02/2021 10:00:41
|
