C # объект пула с блокировкой.Инкремент - PullRequest
2 голосов
/ 08 сентября 2010

Я видел много хороших реализаций пула объектов.Например: C # Реализация шаблона пула объектов .

Но похоже, что потокобезопасные всегда используют блокировку и никогда не пытаются использовать операции Interlocked. *

Кажется, легко написать тот, который не позволяет возвращать объекты в пул (просто большой массив с указателем Interlocked.Increments).Но я не могу придумать способ написать такой, который позволит вам возвращать объекты.Кто-нибудь делал это?

Ответы [ 6 ]

2 голосов
/ 08 сентября 2010

Я сделал это с помощью очереди без блокировки, построенной как односвязный список.Ниже вычеркнуты некоторые не относящиеся к делу вещи, и я не проверял их с удаленными вещами, но, по крайней мере, должен дать идею.

internal sealed class LockFreeQueue<T>
{
  private sealed class Node
  {
    public readonly T Item;
    public Node Next;
    public Node(T item)
    {
      Item = item;
    }
  }
  private volatile Node _head;
  private volatile Node _tail;
  public LockFreeQueue()
  {
    _head = _tail = new Node(default(T));
  }
#pragma warning disable 420 // volatile semantics not lost as only by-ref calls are interlocked
  public void Enqueue(T item)
  {
    Node newNode = new Node(item);
    for(;;)
    {
      Node curTail = _tail;
      if (Interlocked.CompareExchange(ref curTail.Next, newNode, null) == null)   //append to the tail if it is indeed the tail.
      {
        Interlocked.CompareExchange(ref _tail, newNode, curTail);   //CAS in case we were assisted by an obstructed thread.
        return;
      }
      else
      {
        Interlocked.CompareExchange(ref _tail, curTail.Next, curTail);  //assist obstructing thread.
      }
    }
  }    
  public bool TryDequeue(out T item)
  {
    for(;;)
    {
      Node curHead = _head;
      Node curTail = _tail;
      Node curHeadNext = curHead.Next;
      if (curHead == curTail)
      {
        if (curHeadNext == null)
        {
          item = default(T);
          return false;
        }
        else
          Interlocked.CompareExchange(ref _tail, curHeadNext, curTail);   // assist obstructing thread
      }
      else
      {
        item = curHeadNext.Item;
        if (Interlocked.CompareExchange(ref _head, curHeadNext, curHead) == curHead)
        {
          return true;
        }
      }
    }
  }
#pragma warning restore 420
}

Если ваша причина для объединения была необработанным соображением производительности распределения иКоллекция, а затем тот факт, что это выделяет и собирает, делает его довольно бесполезным.Если это потому, что базовый ресурс дорогой для получения и / или освобождения, или потому что экземпляры кэшируют «изученную» используемую информацию, тогда он может подойти.

2 голосов
/ 08 сентября 2010

Тщательно продумайте, зачем вам нужен пул объектов в любом случае - здесь нет обсуждения объединенных объектов. Для большинства объектов использование управляемой кучи обеспечит необходимую функциональность без головной боли нового менеджера пула в вашем собственном коде. Стоит рассмотреть вопрос об объединении объектов в управляемом коде только в том случае, если ваш объект инкапсулирует трудно устанавливаемые или трудно выпускаемые ресурсы.

Если вам нужно сделать это самостоятельно, тогда существует легкая блокировка чтения / записи, которая может быть полезна для оптимизации доступа к пулу.

http://theburningmonk.com/2010/02/threading-using-readerwriterlockslim/

1 голос
/ 08 сентября 2010

Вы смотрели коллекцию Concurrent в .Net 4.

например, http://msdn.microsoft.com/en-us/library/dd287191.aspx

1 голос
/ 08 сентября 2010

Проблема с возвратом ссылочных объектов заключается в том, что в первую очередь она блокирует всю попытку заблокировать доступ к нему. Вы не можете использовать базовую команду lock () для управления доступом к ресурсу, находящемуся за пределами объекта, и это означает, что традиционные схемы получения / установки не работают.

То, что МОЖЕТ работать, - это объект, который содержит блокируемые ресурсы и позволяет передавать лямбды или делегаты, которые будут использовать ресурс. Объект заблокирует ресурс, запустит делегат, а затем разблокирует, когда делегат завершит работу. Это в основном передает управление выполнением кода в руки объекта блокировки, но позволяет выполнять более сложные операции, чем доступно для Interlocked.

Еще один возможный метод - показать геттеры и сеттеры, но реализовать свой собственный контроль доступа, используя модель «checkout»; когда потоку разрешено «получить» значение, сохраните ссылку на текущий поток в заблокированном внутреннем ресурсе. До тех пор, пока этот поток не вызовет установщик, прервет и т. Д., Все другие потоки, пытающиеся получить доступ к получателю, будут оставаться в цикле доходности. Как только ресурс будет возвращен обратно, его может получить следующий поток.

public class Library
{
   private Book controlledBook
   private Thread checkoutThread;

   public Book CheckOutTheBook()
   {
      while(Thread.CurrentThread != checkoutThread && checkoutThread.IsAlive)
          thread.CurrentThread.Yield();

      lock(this)
      {
         checkoutThread = Thread.CurrentThread;

         return controlledBook;
      }
   }

   public void CheckInTheBook(Book theBook)
   {
      if(Thread.CurrentThread != checkoutThread)
          throw new InvalidOperationException("This thread does not have the resource checked out.");

      lock(this)
      {
         checkoutThread = null;

         controlledBook = theBook;
      }
   }

}

Теперь имейте в виду, что это все еще требует некоторого сотрудничества между пользователями объекта. В частности, эта логика довольно наивна по отношению к сеттеру; невозможно проверить книгу, не проверив ее. Это правило может быть неочевидным для потребителей, и неправильное использование может стать причиной необработанного исключения. Кроме того, все пользователи должны знать, чтобы вернуть объект обратно, если они прекратят его использовать до того, как прекратят работу, хотя базовые знания C # будут диктовать, что если вы получаете ссылочный тип, внесенные вами изменения отражаются повсеместно. Тем не менее, это может использоваться как базовый контроль доступа «по одному» к не поточнобезопасному ресурсу.

0 голосов
/ 22 декабря 2017

Хороший вопрос. При написании высокопроизводительного программного обеспечения использование шаблонов с нулевым распределением с использованием быстрого пула объектов имеет решающее значение.

Microsoft выпустила пул объектов под лицензией Apache 2.0

Он избегает использования блокировок и использует только Interlocked.CompareExchange for Allocations (Get). Это кажется особенно быстрым, когда вы получаете и отпускаете несколько объектов за раз, что в большинстве случаев используется. Это кажется менее оптимизированным, если вы получаете большой пакет объектов, а затем выпустите пакет, так что если ваше приложение ведет себя так, как вам нужно изменить.

Я думаю, что подход Interlocked.Increment, как вы предложили, может быть более общим и лучше работать для случаев пакетного использования.

http://source.roslyn.io/#Microsoft.CodeAnalysis.Workspaces/ObjectPool%25601.cs,98aa6d9b3c4e313b

// Copyright (c) Microsoft.  All Rights Reserved.  Licensed under the Apache License, Version 2.0.  See License.txt in the project root for license information.

// define TRACE_LEAKS to get additional diagnostics that can lead to the leak sources. note: it will
// make everything about 2-3x slower
// 
// #define TRACE_LEAKS

// define DETECT_LEAKS to detect possible leaks
// #if DEBUG
// #define DETECT_LEAKS  //for now always enable DETECT_LEAKS in debug.
// #endif

using System;
using System.Diagnostics;
using System.Threading;

#if DETECT_LEAKS
using System.Runtime.CompilerServices;

#endif
namespace Microsoft.CodeAnalysis.PooledObjects
{
    /// <summary>
    /// Generic implementation of object pooling pattern with predefined pool size limit. The main
    /// purpose is that limited number of frequently used objects can be kept in the pool for
    /// further recycling.
    /// 
    /// Notes: 
    /// 1) it is not the goal to keep all returned objects. Pool is not meant for storage. If there
    ///    is no space in the pool, extra returned objects will be dropped.
    /// 
    /// 2) it is implied that if object was obtained from a pool, the caller will return it back in
    ///    a relatively short time. Keeping checked out objects for long durations is ok, but 
    ///    reduces usefulness of pooling. Just new up your own.
    /// 
    /// Not returning objects to the pool in not detrimental to the pool's work, but is a bad practice. 
    /// Rationale: 
    ///    If there is no intent for reusing the object, do not use pool - just use "new". 
    /// </summary>
    internal class ObjectPool<T> where T : class
    {
        [DebuggerDisplay("{Value,nq}")]
        private struct Element
        {
            internal T Value;
        }

        /// <remarks>
        /// Not using System.Func{T} because this file is linked into the (debugger) Formatter,
        /// which does not have that type (since it compiles against .NET 2.0).
        /// </remarks>
        internal delegate T Factory();

        // Storage for the pool objects. The first item is stored in a dedicated field because we
        // expect to be able to satisfy most requests from it.
        private T _firstItem;
        private readonly Element[] _items;

        // factory is stored for the lifetime of the pool. We will call this only when pool needs to
        // expand. compared to "new T()", Func gives more flexibility to implementers and faster
        // than "new T()".
        private readonly Factory _factory;

#if DETECT_LEAKS
        private static readonly ConditionalWeakTable<T, LeakTracker> leakTrackers = new ConditionalWeakTable<T, LeakTracker>();

        private class LeakTracker : IDisposable
        {
            private volatile bool disposed;

#if TRACE_LEAKS
            internal volatile object Trace = null;
#endif

            public void Dispose()
            {
                disposed = true;
                GC.SuppressFinalize(this);
            }

            private string GetTrace()
            {
#if TRACE_LEAKS
                return Trace == null ? "" : Trace.ToString();
#else
                return "Leak tracing information is disabled. Define TRACE_LEAKS on ObjectPool`1.cs to get more info \n";
#endif
            }

            ~LeakTracker()
            {
                if (!this.disposed && !Environment.HasShutdownStarted)
                {
                    var trace = GetTrace();

                    // If you are seeing this message it means that object has been allocated from the pool 
                    // and has not been returned back. This is not critical, but turns pool into rather 
                    // inefficient kind of "new".
                    Debug.WriteLine($"TRACEOBJECTPOOLLEAKS_BEGIN\nPool detected potential leaking of {typeof(T)}. \n Location of the leak: \n {GetTrace()} TRACEOBJECTPOOLLEAKS_END");
                }
            }
        }
#endif

        internal ObjectPool(Factory factory)
            : this(factory, Environment.ProcessorCount * 2)
        { }

        internal ObjectPool(Factory factory, int size)
        {
            Debug.Assert(size >= 1);
            _factory = factory;
            _items = new Element[size - 1];
        }

        private T CreateInstance()
        {
            var inst = _factory();
            return inst;
        }

        /// <summary>
        /// Produces an instance.
        /// </summary>
        /// <remarks>
        /// Search strategy is a simple linear probing which is chosen for it cache-friendliness.
        /// Note that Free will try to store recycled objects close to the start thus statistically 
        /// reducing how far we will typically search.
        /// </remarks>
        internal T Allocate()
        {
            // PERF: Examine the first element. If that fails, AllocateSlow will look at the remaining elements.
            // Note that the initial read is optimistically not synchronized. That is intentional. 
            // We will interlock only when we have a candidate. in a worst case we may miss some
            // recently returned objects. Not a big deal.
            T inst = _firstItem;
            if (inst == null || inst != Interlocked.CompareExchange(ref _firstItem, null, inst))
            {
                inst = AllocateSlow();
            }

#if DETECT_LEAKS
            var tracker = new LeakTracker();
            leakTrackers.Add(inst, tracker);

#if TRACE_LEAKS
            var frame = CaptureStackTrace();
            tracker.Trace = frame;
#endif
#endif
            return inst;
        }

        private T AllocateSlow()
        {
            var items = _items;

            for (int i = 0; i < items.Length; i++)
            {
                // Note that the initial read is optimistically not synchronized. That is intentional. 
                // We will interlock only when we have a candidate. in a worst case we may miss some
                // recently returned objects. Not a big deal.
                T inst = items[i].Value;
                if (inst != null)
                {
                    if (inst == Interlocked.CompareExchange(ref items[i].Value, null, inst))
                    {
                        return inst;
                    }
                }
            }

            return CreateInstance();
        }

        /// <summary>
        /// Returns objects to the pool.
        /// </summary>
        /// <remarks>
        /// Search strategy is a simple linear probing which is chosen for it cache-friendliness.
        /// Note that Free will try to store recycled objects close to the start thus statistically 
        /// reducing how far we will typically search in Allocate.
        /// </remarks>
        internal void Free(T obj)
        {
            Validate(obj);
            ForgetTrackedObject(obj);

            if (_firstItem == null)
            {
                // Intentionally not using interlocked here. 
                // In a worst case scenario two objects may be stored into same slot.
                // It is very unlikely to happen and will only mean that one of the objects will get collected.
                _firstItem = obj;
            }
            else
            {
                FreeSlow(obj);
            }
        }

        private void FreeSlow(T obj)
        {
            var items = _items;
            for (int i = 0; i < items.Length; i++)
            {
                if (items[i].Value == null)
                {
                    // Intentionally not using interlocked here. 
                    // In a worst case scenario two objects may be stored into same slot.
                    // It is very unlikely to happen and will only mean that one of the objects will get collected.
                    items[i].Value = obj;
                    break;
                }
            }
        }

        /// <summary>
        /// Removes an object from leak tracking.  
        /// 
        /// This is called when an object is returned to the pool.  It may also be explicitly 
        /// called if an object allocated from the pool is intentionally not being returned
        /// to the pool.  This can be of use with pooled arrays if the consumer wants to 
        /// return a larger array to the pool than was originally allocated.
        /// </summary>
        [Conditional("DEBUG")]
        internal void ForgetTrackedObject(T old, T replacement = null)
        {
#if DETECT_LEAKS
            LeakTracker tracker;
            if (leakTrackers.TryGetValue(old, out tracker))
            {
                tracker.Dispose();
                leakTrackers.Remove(old);
            }
            else
            {
                var trace = CaptureStackTrace();
                Debug.WriteLine($"TRACEOBJECTPOOLLEAKS_BEGIN\nObject of type {typeof(T)} was freed, but was not from pool. \n Callstack: \n {trace} TRACEOBJECTPOOLLEAKS_END");
            }

            if (replacement != null)
            {
                tracker = new LeakTracker();
                leakTrackers.Add(replacement, tracker);
            }
#endif
        }

#if DETECT_LEAKS
        private static Lazy<Type> _stackTraceType = new Lazy<Type>(() => Type.GetType("System.Diagnostics.StackTrace"));

        private static object CaptureStackTrace()
        {
            return Activator.CreateInstance(_stackTraceType.Value);
        }
#endif

        [Conditional("DEBUG")]
        private void Validate(object obj)
        {
            Debug.Assert(obj != null, "freeing null?");

            Debug.Assert(_firstItem != obj, "freeing twice?");

            var items = _items;
            for (int i = 0; i < items.Length; i++)
            {
                var value = items[i].Value;
                if (value == null)
                {
                    return;
                }

                Debug.Assert(value != obj, "freeing twice?");
            }
        }
    }
}
0 голосов
/ 08 сентября 2010

Я не вижу никакой реальной выгоды в использовании Interlocked, а также в том, что он должен использоваться небезопасным образом. Lock, только изменяет битовый флаг в области памяти объекта - действительно очень быстро. Блокировка немного лучше, так как это может быть сделано в регистрах, а не в памяти.

У вас проблемы с производительностью? Какова основная цель такого кода? В конце концов, C # разработан для отвлечения от вас управления памятью, чтобы вы могли сосредоточиться на своей бизнес-проблеме.

Помните, что если вам нужно самостоятельно управлять памятью и использовать небезопасные указатели, вы должны закрепить область памяти = дополнительные затраты производительности.

...