Fixe la taille de la file d'attente qui retire automatiquement les anciennes valeurs sur les nouveaux enques

Je voudrais écrire une classe wrapper sur la mise en File d'attente serait de vérifier le Comte, puis file d'attente lorsque le nombre dépasse la limite.

 public class FixedSizedQueue<T>
 {
     ConcurrentQueue<T> q = new ConcurrentQueue<T>();
     private object lockObject = new object();

     public int Limit { get; set; }
     public void Enqueue(T obj)
     {
        q.Enqueue(obj);
        lock (lockObject)
        {
           T overflow;
           while (q.Count > Limit && q.TryDequeue(out overflow)) ;
        }
     }
 }

Pour toute personne qui estime utile, voici un peu de code de travail basé sur Richard Schneider réponse ci-dessus:

public class FixedSizedQueue<T>
{
    readonly ConcurrentQueue<T> queue = new ConcurrentQueue<T>();

    public int Size { get; private set; }

    public FixedSizedQueue(int size)
    {
        Size = size;
    }

    public void Enqueue(T obj)
    {
        queue.Enqueue(obj);

        while (queue.Count > Size)
        {
            T outObj;
            queue.TryDequeue(out outObj);
        }
    }
}

Voici mon point de vue sur le fixe de la taille de la File d'attente

Il utilise régulièrement la File d'attente, afin d'éviter la synchronisation de charge lorsque la Count propriété est utilisée sur ConcurrentQueue. Il met également en œuvre IReadOnlyCollection de sorte que LINQ méthodes peuvent être utilisées. Le reste est très similaire à d'autres réponses ici.

[Serializable]
[DebuggerDisplay("Count = {" + nameof(Count) + "}, Limit = {" + nameof(Limit) + "}")]
public class FixedSizedQueue<T> : IReadOnlyCollection<T>
{
private readonly Queue<T> _queue = new Queue<T>();
private readonly object _lock = new object();
public int Count { get { lock (_lock) { return _queue.Count; } } }
public int Limit { get; }
public FixedSizedQueue(int limit)
{
if (limit < 1)
throw new ArgumentOutOfRangeException(nameof(limit));
Limit = limit;
}
public FixedSizedQueue(IEnumerable<T> collection)
{
if (collection is null || !collection.Any())
throw new ArgumentException("Can not initialize the Queue with a null or empty collection", nameof(collection));
_queue = new Queue<T>(collection);
Limit = _queue.Count;
}
public void Enqueue(T obj)
{
lock (_lock)
{
_queue.Enqueue(obj);
while (_queue.Count > Limit)
_queue.Dequeue();
}
}
public void Clear()
{
lock (_lock)
_queue.Clear();
}
public IEnumerator<T> GetEnumerator()
{
lock (_lock)
return new List<T>(_queue).GetEnumerator();
}
IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
}

Ma version est juste une sous-classe de la normale Queue ceux.. rien de spécial mais en voyant tous les participants et il va encore avec le titre de la rubrique, je pourrais tout aussi bien le mettre ici. Il renvoie également le dequeued juste au cas où.

public sealed class SizedQueue<T> : Queue<T>
{
public int FixedCapacity { get; }
public SizedQueue(int fixedCapacity)
{
this.FixedCapacity = fixedCapacity;
}
///<summary>
///If the total number of item exceed the capacity, the oldest ones automatically dequeues.
///</summary>
///<returns>The dequeued value, if any.</returns>
public new T Enqueue(T item)
{
base.Enqueue(item);
if (base.Count > FixedCapacity)
{
return base.Dequeue();
}
return default;
}
}

Ajoutons une réponse de plus. Pourquoi ce au détriment des autres?

1) la Simplicité. Essayer de garantir la taille est bien, mais conduit à l'inutile complexité que peut présenter ses propres problèmes.

2) met en œuvre IReadOnlyCollection, ce qui signifie que vous pouvez utiliser Linq sur elle et la passer dans une variété de choses qui attendent IEnumerable.

3) Pas de verrouillage. Plusieurs des solutions ci-dessus utilisent des verrous, ce qui est incorrect sur un lockless collection.

4) met en œuvre les mêmes méthodes, les propriétés et les interfaces ConcurrentQueue, y compris IProducerConsumerCollection, ce qui est important si vous souhaitez utiliser la collection avec BlockingCollection.

Cette mise en œuvre pourrait potentiellement se retrouver avec plus d'entrées que prévu si TryDequeue échoue, mais la fréquence de celle qui se produit ne semble pas la peine de code spécialisé qui ne manqueront pas de gêner la performance et de la cause de ses propres problèmes inattendus.

Si vous voulez absolument garantir une taille, la mise en œuvre d'une Prune() ou une méthode similaire semble être la meilleure idée. Vous pouvez utiliser un ReaderWriterLockSlim verrou en lecture dans les autres méthodes (y compris TryDequeue) et de prendre un verrou en écriture uniquement lorsque la taille.

class ConcurrentFixedSizeQueue<T> : IProducerConsumerCollection<T>, IReadOnlyCollection<T>, ICollection {
readonly ConcurrentQueue<T> m_concurrentQueue;
readonly int m_maxSize;
public int Count => m_concurrentQueue.Count;
public bool IsEmpty => m_concurrentQueue.IsEmpty;
public ConcurrentFixedSizeQueue (int maxSize) : this(Array.Empty<T>(), maxSize) { }
public ConcurrentFixedSizeQueue (IEnumerable<T> initialCollection, int maxSize) {
if (initialCollection == null) {
throw new ArgumentNullException(nameof(initialCollection));
}
m_concurrentQueue = new ConcurrentQueue<T>(initialCollection);
m_maxSize = maxSize;
}
public void Enqueue (T item) {
m_concurrentQueue.Enqueue(item);
if (m_concurrentQueue.Count > m_maxSize) {
T result;
m_concurrentQueue.TryDequeue(out result);
}
}
public void TryPeek (out T result) => m_concurrentQueue.TryPeek(out result);
public bool TryDequeue (out T result) => m_concurrentQueue.TryDequeue(out result);
public void CopyTo (T[] array, int index) => m_concurrentQueue.CopyTo(array, index);
public T[] ToArray () => m_concurrentQueue.ToArray();
public IEnumerator<T> GetEnumerator () => m_concurrentQueue.GetEnumerator();
IEnumerator IEnumerable.GetEnumerator () => GetEnumerator();
//Explicit ICollection implementations.
void ICollection.CopyTo (Array array, int index) => ((ICollection)m_concurrentQueue).CopyTo(array, index);
object ICollection.SyncRoot => ((ICollection) m_concurrentQueue).SyncRoot;
bool ICollection.IsSynchronized => ((ICollection) m_concurrentQueue).IsSynchronized;
//Explicit IProducerConsumerCollection<T> implementations.
bool IProducerConsumerCollection<T>.TryAdd (T item) => ((IProducerConsumerCollection<T>) m_concurrentQueue).TryAdd(item);
bool IProducerConsumerCollection<T>.TryTake (out T item) => ((IProducerConsumerCollection<T>) m_concurrentQueue).TryTake(out item);
public override int GetHashCode () => m_concurrentQueue.GetHashCode();
public override bool Equals (object obj) => m_concurrentQueue.Equals(obj);
public override string ToString () => m_concurrentQueue.ToString();
}

C'est ma version de la file d'attente:

public class FixedSizedQueue<T> {
private object LOCK = new object();
ConcurrentQueue<T> queue;
public int MaxSize { get; set; }
public FixedSizedQueue(int maxSize, IEnumerable<T> items = null) {
this.MaxSize = maxSize;
if (items == null) {
queue = new ConcurrentQueue<T>();
}
else {
queue = new ConcurrentQueue<T>(items);
EnsureLimitConstraint();
}
}
public void Enqueue(T obj) {
queue.Enqueue(obj);
EnsureLimitConstraint();
}
private void EnsureLimitConstraint() {
if (queue.Count > MaxSize) {
lock (LOCK) {
T overflow;
while (queue.Count > MaxSize) {
queue.TryDequeue(out overflow);
}
}
}
}
///<summary>
///returns the current snapshot of the queue
///</summary>
///<returns></returns>
public T[] GetSnapshot() {
return queue.ToArray();
}
}

Je trouve qu'il est utile d'avoir un constructeur qui est construit sur un IEnumerable et je trouve qu'il est utile d'avoir un GetSnapshot d'avoir un multi thread safe liste (array dans ce cas) des objets au moment de l'appel, qui ne remonte pas des erreurs si le sous-jacente de la collection de changements.

Le double Comptage vérification est pour éviter le blocage dans certaines circonstances.