Pas de ConcurrentList <T> dans .Net 4.0?

J'étais ravi de voir le nouvel System.Collections.Concurrentespace de noms dans .Net 4.0, plutôt sympa! Je l' ai vu ConcurrentDictionary, ConcurrentQueue, ConcurrentStack, ConcurrentBaget BlockingCollection.

Une chose qui semble mystérieusement manquer est a ConcurrentList<T>. Dois-je l'écrire moi-même (ou le retirer du Web :))?

Suis-je en train de manquer quelque chose d'évident ici?

Je l'ai essayé il y a quelque temps (aussi: sur GitHub ). Mon implémentation a eu quelques problèmes, que je n'entrerai pas ici. Permettez-moi de vous dire, plus important encore, ce que j'ai appris.

Tout d'abord, il n'y a aucun moyen d'obtenir une implémentation complète de IList<T> qui soit sans verrou et sans thread. En particulier, les insertions et les suppressions aléatoires ne fonctionneront pas, sauf si vous oubliez également l'accès aléatoire O (1) (c'est-à-dire, sauf si vous "trichez" et utilisez simplement une sorte de liste chaînée et laissez l'indexation aspirer).

Ce que je pensais peut - être utile était un thread-safe, sous - ensemble limité de IList<T>: en particulier, qui permettrait à un Addet de fournir au hasard en lecture seule l' accès par index (mais non Insert, RemoveAtetc., et pas non plus au hasard écrire un accès).

C'était le but de ma ConcurrentList<T>mise en œuvre . Mais lorsque j'ai testé ses performances dans des scénarios multithread, j'ai constaté que la simple synchronisation s'ajoute à a List<T>était plus rapide . Fondamentalement, l'ajout à un List<T>est déjà rapide comme l'éclair; la complexité des étapes de calcul impliquées est minuscule (incrémenter un index et l'assigner à un élément dans un tableau; c'est vraiment ça ). Vous auriez besoin d'une tonne d'écritures simultanées pour voir toute sorte de conflit de verrouillage à ce sujet; et même dans ce cas, les performances moyennes de chaque écriture l'emporteraient toujours sur l'implémentation sans verrou plus coûteuse ConcurrentList<T>.

Dans le cas relativement rare où le tableau interne de la liste doit se redimensionner, vous payez un petit coût. Donc, finalement, j'ai conclu que c'était le seul scénario de niche où un ConcurrentList<T>type de collection à ajouter uniquement aurait du sens: lorsque vous voulez garantir une faible surcharge de l'ajout d'un élément sur chaque appel (donc, par opposition à un objectif de performance amorti).

Ce n'est tout simplement pas une classe aussi utile que vous le pensez.

Pour quoi utiliseriez-vous une ConcurrentList?

Le concept d'un conteneur à accès aléatoire dans un monde fileté n'est pas aussi utile qu'il y paraît. La déclaration

  if (i < MyConcurrentList.Count)  
      x = MyConcurrentList[i]; 

dans son ensemble ne serait toujours pas thread-safe.

Au lieu de créer une liste concurrente, essayez de créer des solutions avec ce qui existe. Les classes les plus courantes sont le ConcurrentBag et en particulier le BlockingCollection.

Avec tout le respect que je dois aux bonnes réponses déjà fournies, il y a des moments où je veux simplement une IList thread-safe. Rien d'avancé ou de fantaisie. Les performances sont importantes dans de nombreux cas, mais parfois ce n'est pas un problème. Oui, il y aura toujours des défis sans méthodes comme "TryGetValue", etc., mais la plupart des cas, je veux juste quelque chose que je peux énumérer sans avoir à se soucier de mettre des verrous autour de tout. Et oui, quelqu'un peut probablement trouver un "bogue" dans mon implémentation qui pourrait conduire à un blocage ou quelque chose (je suppose), mais soyons honnêtes: en ce qui concerne le multithread, si vous n'écrivez pas correctement votre code, il va de toute façon à l'impasse. Dans cet esprit, j'ai décidé de faire une implémentation ConcurrentList simple qui répond à ces besoins de base.

Et pour ce que ça vaut: j'ai fait un test de base pour ajouter 10 000 000 d'éléments à List et ConcurrentList standard et les résultats ont été:

Liste terminée en: 7793 millisecondes. Concurrent terminé en: 8064 millisecondes.

public class ConcurrentList<T> : IList<T>, IDisposable
{
    #region Fields
    private readonly List<T> _list;
    private readonly ReaderWriterLockSlim _lock;
    #endregion

    #region Constructors
    public ConcurrentList()
    {
        this._lock = new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion);
        this._list = new List<T>();
    }

    public ConcurrentList(int capacity)
    {
        this._lock = new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion);
        this._list = new List<T>(capacity);
    }

    public ConcurrentList(IEnumerable<T> items)
    {
        this._lock = new ReaderWriterLockSlim(LockRecursionPolicy.NoRecursion);
        this._list = new List<T>(items);
    }
    #endregion

    #region Methods
    public void Add(T item)
    {
        try
        {
            this._lock.EnterWriteLock();
            this._list.Add(item);
        }
        finally
        {
            this._lock.ExitWriteLock();
        }
    }

    public void Insert(int index, T item)
    {
        try
        {
            this._lock.EnterWriteLock();
            this._list.Insert(index, item);
        }
        finally
        {
            this._lock.ExitWriteLock();
        }
    }

    public bool Remove(T item)
    {
        try
        {
            this._lock.EnterWriteLock();
            return this._list.Remove(item);
        }
        finally
        {
            this._lock.ExitWriteLock();
        }
    }

    public void RemoveAt(int index)
    {
        try
        {
            this._lock.EnterWriteLock();
            this._list.RemoveAt(index);
        }
        finally
        {
            this._lock.ExitWriteLock();
        }
    }

    public int IndexOf(T item)
    {
        try
        {
            this._lock.EnterReadLock();
            return this._list.IndexOf(item);
        }
        finally
        {
            this._lock.ExitReadLock();
        }
    }

    public void Clear()
    {
        try
        {
            this._lock.EnterWriteLock();
            this._list.Clear();
        }
        finally
        {
            this._lock.ExitWriteLock();
        }
    }

    public bool Contains(T item)
    {
        try
        {
            this._lock.EnterReadLock();
            return this._list.Contains(item);
        }
        finally
        {
            this._lock.ExitReadLock();
        }
    }

    public void CopyTo(T[] array, int arrayIndex)
    {
        try
        {
            this._lock.EnterReadLock();
            this._list.CopyTo(array, arrayIndex);
        }
        finally
        {
            this._lock.ExitReadLock();
        }
    }

    public IEnumerator<T> GetEnumerator()
    {
        return new ConcurrentEnumerator<T>(this._list, this._lock);
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return new ConcurrentEnumerator<T>(this._list, this._lock);
    }

    ~ConcurrentList()
    {
        this.Dispose(false);
    }

    public void Dispose()
    {
        this.Dispose(true);
    }

    private void Dispose(bool disposing)
    {
        if (disposing)
            GC.SuppressFinalize(this);

        this._lock.Dispose();
    }
    #endregion

    #region Properties
    public T this[int index]
    {
        get
        {
            try
            {
                this._lock.EnterReadLock();
                return this._list[index];
            }
            finally
            {
                this._lock.ExitReadLock();
            }
        }
        set
        {
            try
            {
                this._lock.EnterWriteLock();
                this._list[index] = value;
            }
            finally
            {
                this._lock.ExitWriteLock();
            }
        }
    }

    public int Count
    {
        get
        {
            try
            {
                this._lock.EnterReadLock();
                return this._list.Count;
            }
            finally
            {
                this._lock.ExitReadLock();
            }
        }
    }

    public bool IsReadOnly
    {
        get { return false; }
    }
    #endregion
}

    public class ConcurrentEnumerator<T> : IEnumerator<T>
{
    #region Fields
    private readonly IEnumerator<T> _inner;
    private readonly ReaderWriterLockSlim _lock;
    #endregion

    #region Constructor
    public ConcurrentEnumerator(IEnumerable<T> inner, ReaderWriterLockSlim @lock)
    {
        this._lock = @lock;
        this._lock.EnterReadLock();
        this._inner = inner.GetEnumerator();
    }
    #endregion

    #region Methods
    public bool MoveNext()
    {
        return _inner.MoveNext();
    }

    public void Reset()
    {
        _inner.Reset();
    }

    public void Dispose()
    {
        this._lock.ExitReadLock();
    }
    #endregion

    #region Properties
    public T Current
    {
        get { return _inner.Current; }
    }

    object IEnumerator.Current
    {
        get { return _inner.Current; }
    }
    #endregion
}

ConcurrentList(comme un tableau redimensionnable, pas une liste chaînée) n'est pas facile à écrire avec des opérations non bloquantes. Son API ne se traduit pas bien en une version "simultanée".

La raison pour laquelle il n'y a pas de ConcurrentList est qu'elle ne peut fondamentalement pas être écrite. La raison en est que plusieurs opérations importantes dans IList reposent sur des indices, et cela ne fonctionnera tout simplement pas. Par exemple:

int catIndex = list.IndexOf("cat");
list.Insert(catIndex, "dog");

L'effet recherché par l'auteur est d'insérer "chien" avant "chat", mais dans un environnement multithread, tout peut arriver à la liste entre ces deux lignes de code. Par exemple, un autre thread pourrait faire list.RemoveAt(0), en déplaçant la liste entière vers la gauche, mais surtout, catIndex ne changera pas. L'impact ici est que l' Insertopération mettra en fait le «chien» après le chat, pas avant lui.

Les nombreuses implémentations que vous voyez comme «réponses» à cette question sont bien intentionnées, mais comme le montre ce qui précède, elles n'offrent pas de résultats fiables. Si vous voulez vraiment une sémantique de type liste dans un environnement multithread, vous ne pouvez pas y arriver en mettant des verrous à l' intérieur les méthodes d'implémentation de la liste. Vous devez vous assurer que tout index que vous utilisez vit entièrement dans le contexte du verrou. Le résultat est que vous pouvez utiliser une liste dans un environnement multithread avec le bon verrouillage, mais la liste elle-même ne peut pas être créée pour exister dans ce monde.

Si vous pensez avoir besoin d'une liste simultanée, il n'y a vraiment que deux possibilités:

1. Ce dont vous avez vraiment besoin, c'est d'un ConcurrentBag
2. Vous devez créer votre propre collection, peut-être implémentée avec une liste et votre propre contrôle de concurrence.

Si vous avez un ConcurrentBag et que vous devez le passer en tant qu'IList, vous avez un problème, car la méthode que vous appelez a spécifié qu'ils pourraient essayer de faire quelque chose comme je l'ai fait ci-dessus avec le chat & chien. Dans la plupart des mondes, cela signifie que la méthode que vous appelez n'est tout simplement pas conçue pour fonctionner dans un environnement multithread. Cela signifie que vous devez le refactoriser pour qu'il soit ou, si vous ne le pouvez pas, vous devrez le gérer très soigneusement. Vous devrez presque certainement créer votre propre collection avec ses propres verrous et appeler la méthode incriminée dans un verrou.

Dans les cas où les lectures sont beaucoup plus nombreuses que les écritures ou (même si elles sont fréquentes) les écritures ne sont pas simultanées , une approche de copie sur écriture peut être appropriée.

L'implémentation illustrée ci-dessous est

• sans verrou
• incroyablement rapide pour les lectures simultanées , même si les modifications simultanées sont en cours - peu importe le temps qu'elles prennent
• parce que les "instantanés" sont immuables, une atomicité sans verrou est possible, c'est-à-dire var snap = _list; snap[snap.Count - 1];qu'elle ne lancera jamais (enfin, sauf pour une liste vide bien sûr), et vous obtenez également une énumération thread-safe avec la sémantique des instantanés gratuitement .. comment j'aime l'immuabilité!
• implémenté de manière générique , applicable à toute structure de données et tout type de modification
• mort simple , c'est-à-dire facile à tester, à déboguer, à vérifier en lisant le code
• utilisable dans .Net 3.5

Pour que la copie sur écriture fonctionne, vous devez conserver vos structures de données effectivement immuables , c'est-à-dire que personne n'est autorisé à les modifier après les avoir mises à la disposition d'autres threads. Lorsque vous souhaitez modifier, vous

1. cloner la structure
2. faire des modifications sur le clone
3. permuter atomiquement dans la référence au clone modifié

Code

static class CopyOnWriteSwapper
{
    public static void Swap<T>(ref T obj, Func<T, T> cloner, Action<T> op)
        where T : class
    {
        while (true)
        {
            var objBefore = Volatile.Read(ref obj);
            var newObj = cloner(objBefore);
            op(newObj);
            if (Interlocked.CompareExchange(ref obj, newObj, objBefore) == objBefore)
                return;
        }
    }
}

Usage

CopyOnWriteSwapper.Swap(ref _myList,
    orig => new List<string>(orig),
    clone => clone.Add("asdf"));

Si vous avez besoin de plus de performances, cela aidera à dégénérer la méthode, par exemple créer une méthode pour chaque type de modification (Ajouter, Supprimer, ...) que vous voulez, et coder en dur les pointeurs de fonction cloneret op.

NB # 1 Il est de votre responsabilité de vous assurer que personne ne modifie la structure de données (supposée) immuable. Il n'y a rien que nous puissions faire dans une implémentation générique pour empêcher cela, mais lors de la spécialisation List<T>, vous pouvez vous prémunir contre les modifications à l'aide de List.AsReadOnly ()

NB # 2 Faites attention aux valeurs de la liste. L'approche de copie en écriture ci-dessus protège uniquement leur appartenance à la liste, mais si vous ne mettez pas de chaînes, mais d'autres objets modifiables, vous devez prendre soin de la sécurité des threads (par exemple, le verrouillage). Mais cela est orthogonal à cette solution et par exemple le verrouillage des valeurs mutables peut être facilement utilisé sans problèmes. Vous devez juste en être conscient.

NB # 3 Si votre structure de données est énorme et que vous la modifiez fréquemment, l'approche copier-tout-sur-écriture peut être prohibitive à la fois en termes de consommation de mémoire et de coût CPU de copie. Dans ce cas, vous pouvez utiliser à la place les collections immuables de MS .

System.Collections.Generic.List<t>est déjà thread-safe pour plusieurs lecteurs. Essayer de le rendre sûr pour les threads pour plusieurs écrivains n'aurait aucun sens. (Pour des raisons que Henk et Stephen ont déjà mentionnées)

Certaines personnes ont signalé certains points positifs (et certaines de mes pensées):

• Il peut sembler fou à un accesseur aléatoire (indexeur) incapable, mais pour moi, cela semble bien. Il suffit de penser qu'il existe de nombreuses méthodes sur les collections multi-thread qui pourraient échouer comme Indexer et Delete. Vous pouvez également définir une action d'échec (repli) pour l'accesseur d'écriture comme «échouer» ou simplement «ajouter à la fin».
• Ce n'est pas parce que c'est une collection multithread qu'elle sera toujours utilisée dans un contexte multithread. Ou il pourrait également être utilisé par un seul écrivain et un seul lecteur.
• Une autre façon de pouvoir utiliser l'indexeur de manière sûre pourrait être d'encapsuler des actions dans un verrou de la collection en utilisant sa racine (si elle est rendue publique).
• Pour de nombreuses personnes, rendre un rootLock visible devient une "bonne pratique". Je ne suis pas sûr à 100% de ce point car s'il est caché, vous supprimez beaucoup de flexibilité pour l'utilisateur. Nous devons toujours nous rappeler que la programmation multithread n'est pas pour tout le monde. Nous ne pouvons pas empêcher toutes sortes de mauvaises utilisations.
• Microsoft devra faire un certain travail et définir une nouvelle norme pour introduire une utilisation appropriée de la collection multithread. Tout d'abord, l'IEnumerator ne doit pas avoir de moveNext mais doit avoir un GetNext qui retourne vrai ou faux et obtient un paramètre de sortie de type T (de cette façon, l'itération ne serait plus bloquante). De plus, Microsoft utilise déjà "using" en interne dans foreach, mais utilise parfois directement IEnumerator sans l'encapsuler avec "using" (un bogue dans la vue de la collection et probablement à plus d'endroits) - L'utilisation d'encapsulation d'IEnumerator est une pratique recommandée par Microsoft. Ce bug supprime un bon potentiel d'itérateur sûr ... Itérateur qui verrouille la collection dans le constructeur et déverrouille sur sa méthode Dispose - pour une méthode de blocage foreach.

Ce n'est pas une réponse. Ce ne sont que des commentaires qui ne correspondent pas vraiment à un endroit spécifique.

... Ma conclusion, Microsoft doit apporter des modifications profondes à la "foreach" pour rendre la collection MultiThreaded plus facile à utiliser. Il doit également suivre ses propres règles d'utilisation IEnumerator. Jusque-là, nous pouvons facilement écrire une MultiThreadList qui utiliserait un itérateur de blocage mais qui ne suivra pas "IList". Au lieu de cela, vous devrez définir votre propre interface "IListPersonnal" qui pourrait échouer sur "insert", "remove" et accesseur aléatoire (indexeur) sans exception. Mais qui voudra l'utiliser s'il n'est pas standard?

Dans l'exécution séquentielle de code, les structures de données utilisées sont différentes du code (bien écrit) exécutant simultanément. La raison en est que le code séquentiel implique un ordre implicite. Cependant, le code simultané n'implique aucune commande; mieux encore, cela implique l'absence d'un ordre défini!

Pour cette raison, les structures de données avec un ordre implicite (comme la liste) ne sont pas très utiles pour résoudre des problèmes simultanés. Une liste implique un ordre, mais elle ne définit pas clairement ce qu'est cet ordre. De ce fait, l'ordre d'exécution du code manipulant la liste déterminera (dans une certaine mesure) l'ordre implicite de la liste, qui est en conflit direct avec une solution concurrente efficace.

N'oubliez pas que la concurrence est un problème de données, pas un problème de code! Vous ne pouvez pas implémenter le code en premier (ou réécrire le code séquentiel existant) et obtenir une solution concurrente bien conçue. Vous devez d'abord concevoir les structures de données tout en gardant à l'esprit que l'ordre implicite n'existe pas dans un système simultané.

L'approche de copie et d'écriture sans verrou fonctionne très bien si vous ne traitez pas trop d'éléments. Voici une classe que j'ai écrite:

public class CopyAndWriteList<T>
{
    public static List<T> Clear(List<T> list)
    {
        var a = new List<T>(list);
        a.Clear();
        return a;
    }

    public static List<T> Add(List<T> list, T item)
    {
        var a = new List<T>(list);
        a.Add(item);
        return a;
    }

    public static List<T> RemoveAt(List<T> list, int index)
    {
        var a = new List<T>(list);
        a.RemoveAt(index);
        return a;
    }

    public static List<T> Remove(List<T> list, T item)
    {
        var a = new List<T>(list);
        a.Remove(item);
        return a;
    }

}

exemple d'utilisation: commandes_BUY = CopyAndWriteList.Clear (commandes_BUY);

J'en ai implémenté un semblable à celui de Brian . Le mien est différent:

• Je gère directement la baie.
• Je n'entre pas les verrous dans le bloc d'essai.
• J'utilise yield returnpour produire un énumérateur.
• Je soutiens la récursivité des verrous. Cela permet des lectures à partir de la liste pendant l'itération.
• J'utilise des verrous de lecture évolutifs lorsque cela est possible.
• DoSyncet des GetSyncméthodes permettant des interactions séquentielles qui nécessitent un accès exclusif à la liste.

Le code :

public class ConcurrentList<T> : IList<T>, IDisposable
{
    private ReaderWriterLockSlim _lock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion);
    private int _count = 0;

    public int Count
    {
        get
        { 
            _lock.EnterReadLock();
            try
            {           
                return _count;
            }
            finally
            {
                _lock.ExitReadLock();
            }
        }
    }

    public int InternalArrayLength
    { 
        get
        { 
            _lock.EnterReadLock();
            try
            {           
                return _arr.Length;
            }
            finally
            {
                _lock.ExitReadLock();
            }
        }
    }

    private T[] _arr;

    public ConcurrentList(int initialCapacity)
    {
        _arr = new T[initialCapacity];
    }

    public ConcurrentList():this(4)
    { }

    public ConcurrentList(IEnumerable<T> items)
    {
        _arr = items.ToArray();
        _count = _arr.Length;
    }

    public void Add(T item)
    {
        _lock.EnterWriteLock();
        try
        {       
            var newCount = _count + 1;          
            EnsureCapacity(newCount);           
            _arr[_count] = item;
            _count = newCount;                  
        }
        finally
        {
            _lock.ExitWriteLock();
        }       
    }

    public void AddRange(IEnumerable<T> items)
    {
        if (items == null)
            throw new ArgumentNullException("items");

        _lock.EnterWriteLock();

        try
        {           
            var arr = items as T[] ?? items.ToArray();          
            var newCount = _count + arr.Length;
            EnsureCapacity(newCount);           
            Array.Copy(arr, 0, _arr, _count, arr.Length);       
            _count = newCount;
        }
        finally
        {
            _lock.ExitWriteLock();          
        }
    }

    private void EnsureCapacity(int capacity)
    {   
        if (_arr.Length >= capacity)
            return;

        int doubled;
        checked
        {
            try
            {           
                doubled = _arr.Length * 2;
            }
            catch (OverflowException)
            {
                doubled = int.MaxValue;
            }
        }

        var newLength = Math.Max(doubled, capacity);            
        Array.Resize(ref _arr, newLength);
    }

    public bool Remove(T item)
    {
        _lock.EnterUpgradeableReadLock();

        try
        {           
            var i = IndexOfInternal(item);

            if (i == -1)
                return false;

            _lock.EnterWriteLock();
            try
            {   
                RemoveAtInternal(i);
                return true;
            }
            finally
            {               
                _lock.ExitWriteLock();
            }
        }
        finally
        {           
            _lock.ExitUpgradeableReadLock();
        }
    }

    public IEnumerator<T> GetEnumerator()
    {
        _lock.EnterReadLock();

        try
        {    
            for (int i = 0; i < _count; i++)
                // deadlocking potential mitigated by lock recursion enforcement
                yield return _arr[i]; 
        }
        finally
        {           
            _lock.ExitReadLock();
        }
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return this.GetEnumerator();
    }

    public int IndexOf(T item)
    {
        _lock.EnterReadLock();
        try
        {   
            return IndexOfInternal(item);
        }
        finally
        {
            _lock.ExitReadLock();
        }
    }

    private int IndexOfInternal(T item)
    {
        return Array.FindIndex(_arr, 0, _count, x => x.Equals(item));
    }

    public void Insert(int index, T item)
    {
        _lock.EnterUpgradeableReadLock();

        try
        {                       
            if (index > _count)
                throw new ArgumentOutOfRangeException("index"); 

            _lock.EnterWriteLock();
            try
            {       
                var newCount = _count + 1;
                EnsureCapacity(newCount);

                // shift everything right by one, starting at index
                Array.Copy(_arr, index, _arr, index + 1, _count - index);

                // insert
                _arr[index] = item;     
                _count = newCount;
            }
            finally
            {           
                _lock.ExitWriteLock();
            }
        }
        finally
        {
            _lock.ExitUpgradeableReadLock();            
        }


    }

    public void RemoveAt(int index)
    {   
        _lock.EnterUpgradeableReadLock();
        try
        {   
            if (index >= _count)
                throw new ArgumentOutOfRangeException("index");

            _lock.EnterWriteLock();
            try
            {           
                RemoveAtInternal(index);
            }
            finally
            {
                _lock.ExitWriteLock();
            }
        }
        finally
        {
            _lock.ExitUpgradeableReadLock();            
        }
    }

    private void RemoveAtInternal(int index)
    {           
        Array.Copy(_arr, index + 1, _arr, index, _count - index-1);
        _count--;

        // release last element
        Array.Clear(_arr, _count, 1);
    }

    public void Clear()
    {
        _lock.EnterWriteLock();
        try
        {        
            Array.Clear(_arr, 0, _count);
            _count = 0;
        }
        finally
        {           
            _lock.ExitWriteLock();
        }   
    }

    public bool Contains(T item)
    {
        _lock.EnterReadLock();
        try
        {   
            return IndexOfInternal(item) != -1;
        }
        finally
        {           
            _lock.ExitReadLock();
        }
    }

    public void CopyTo(T[] array, int arrayIndex)
    {       
        _lock.EnterReadLock();
        try
        {           
            if(_count > array.Length - arrayIndex)
                throw new ArgumentException("Destination array was not long enough.");

            Array.Copy(_arr, 0, array, arrayIndex, _count);
        }
        finally
        {
            _lock.ExitReadLock();           
        }
    }

    public bool IsReadOnly
    {   
        get { return false; }
    }

    public T this[int index]
    {
        get
        {
            _lock.EnterReadLock();
            try
            {           
                if (index >= _count)
                    throw new ArgumentOutOfRangeException("index");

                return _arr[index]; 
            }
            finally
            {
                _lock.ExitReadLock();               
            }           
        }
        set
        {
            _lock.EnterUpgradeableReadLock();
            try
            {

                if (index >= _count)
                    throw new ArgumentOutOfRangeException("index");

                _lock.EnterWriteLock();
                try
                {                       
                    _arr[index] = value;
                }
                finally
                {
                    _lock.ExitWriteLock();              
                }
            }
            finally
            {
                _lock.ExitUpgradeableReadLock();
            }

        }
    }

    public void DoSync(Action<ConcurrentList<T>> action)
    {
        GetSync(l =>
        {
            action(l);
            return 0;
        });
    }

    public TResult GetSync<TResult>(Func<ConcurrentList<T>,TResult> func)
    {
        _lock.EnterWriteLock();
        try
        {           
            return func(this);
        }
        finally
        {
            _lock.ExitWriteLock();
        }
    }

    public void Dispose()
    {   
        _lock.Dispose();
    }
}