池设计
池设计
最近打算用Redis用在产品中，所以相应会用到Redis .net client.由于自身也是写网络应用方面的所以自然就想了解一下代码看写得怎样．在打开代码的时候第一眼发现比较熟悉的一个对象BufferPool.打开一看发现设计比较特别，在整个Pool的获取和回收上没有用于我们常用的锁对象，也没有用于.ＮＥＴ带的轻量级的自旋锁．而是通过.net提供的原子锁来实现一个简单的自旋锁．
/// <summary>
/// Courtesy of @marcgravell
/// http://code.google.com/p/protobuf-net/source/browse/trunk/protobuf-net/BufferPool.cs
/// </summary>
internal class BufferPool
{
internal static void Flush()
{
for ( int i = 0 ; i < pool.Length; i++ )
{
Interlocked.Exchange( ref pool[i], null ); // and drop the old value on the floor
}
System.Collections.Generic.st
}
private BufferPool() { }
const int PoolSize = 1000 ; // 1.45MB
internal const int BufferLength = 1450 ; // MTU size - some headers
private static readonly object [] pool = new object [PoolSize];
internal static byte [] GetBuffer()
{
object tmp;
for ( int i = 0 ; i < pool.Length; i++ )
{
if ((tmp = Interlocked.Exchange( ref pool[i], null )) != null )
return ( byte [])tmp;
}
return new byte [BufferLength];
}
internal static void ResizeAndFlushLeft( ref byte [] buffer, int toFitAtLeastBytes, int copyFromIndex, int copyBytes)
{
Debug.Assert(buffer != null );
Debug.Assert(toFitAtLeastBytes > buffer.Length);
Debug.Assert(copyFromIndex >= 0 );
Debug.Assert(copyBytes >= 0 );
// try doubling, else match
int newLength = buffer.Length * 2 ;
if (newLength < toFitAtLeastBytes) newLength = toFitAtLeastBytes;
var newBuffer = new byte [newLength];
if (copyBytes > 0 )
{
Buffer.BlockCopy(buffer, copyFromIndex, newBuffer, 0 , copyBytes);
}
if (buffer.Length == BufferLength)
{
ReleaseBufferToPool( ref buffer);
}
buffer = newBuffer;
}
internal static void ReleaseBufferToPool( ref byte [] buffer)
{
if (buffer == null ) return ;
if (buffer.Length == BufferLength)
{
for ( int i = 0 ; i < pool.Length; i++ )
{
if (Interlocked.CompareExchange( ref pool[i], buffer, null ) == null )
{
break ; // found a null; swapped it in
}
}
}
// if no space, just drop it on the floor
buffer = null ;
}
}
刚开始看这代码感觉真的很怪，想为什么不用stack．．如果池经常为空的时候这样操作是很损耗效能．不过经过详细思考后发现其实这种设计如果当buffer占用到回收之间的时间很短那整个设计来看似乎很不错，池出现为空的情况很少基本只会自旋锁几下就可以了，这样做解决一些锁对象的开销；在密集处理情况效果应该不错，以上紧紧是过去设计经验判断的是不是真的还真要具体测验证．
有经验的朋友不知道对这样的设计有什么看法？
可靠、高性能的Socket TCP通讯组件
开源数据库访问组件
c#组件设计交流群：47164588
c# socket :136485198 微博http://weibo.com/ikende
最近打算用Redis用在产品中，所以相应会用到Redis .net client.由于自身也是写网络应用方面的所以自然就想了解一下代码看写得怎样．在打开代码的时候第一眼发现比较熟悉的一个对象BufferPool.打开一看发现设计比较特别，在整个Pool的获取和回收上没有用于我们常用的锁对象，也没有用于.ＮＥＴ带的轻量级的自旋锁．而是通过.net提供的原子锁来实现一个简单的自旋锁．
/// <summary>
/// Courtesy of @marcgravell
/// http://code.google.com/p/protobuf-net/source/browse/trunk/protobuf-net/BufferPool.cs
/// </summary>
internal class BufferPool
{
internal static void Flush()
{
for ( int i = 0 ; i < pool.Length; i++ )
{
Interlocked.Exchange( ref pool[i], null ); // and drop the old value on the floor
}
System.Collections.Generic.st
}
private BufferPool() { }
const int PoolSize = 1000 ; // 1.45MB
internal const int BufferLength = 1450 ; // MTU size - some headers
private static readonly object [] pool = new object [PoolSize];
internal static byte [] GetBuffer()
{
object tmp;
for ( int i = 0 ; i < pool.Length; i++ )
{
if ((tmp = Interlocked.Exchange( ref pool[i], null )) != null )
return ( byte [])tmp;
}
return new byte [BufferLength];
}
internal static void ResizeAndFlushLeft( ref byte [] buffer, int toFitAtLeastBytes, int copyFromIndex, int copyBytes)
{
Debug.Assert(buffer != null );
Debug.Assert(toFitAtLeastBytes > buffer.Length);
Debug.Assert(copyFromIndex >= 0 );
Debug.Assert(copyBytes >= 0 );
// try doubling, else match
int newLength = buffer.Length * 2 ;
if (newLength < toFitAtLeastBytes) newLength = toFitAtLeastBytes;
var newBuffer = new byte [newLength];
if (copyBytes > 0 )
{
Buffer.BlockCopy(buffer, copyFromIndex, newBuffer, 0 , copyBytes);
}
if (buffer.Length == BufferLength)
{
ReleaseBufferToPool( ref buffer);
}
buffer = newBuffer;
}
internal static void ReleaseBufferToPool( ref byte [] buffer)
{
if (buffer == null ) return ;
if (buffer.Length == BufferLength)
{
for ( int i = 0 ; i < pool.Length; i++ )
{
if (Interlocked.CompareExchange( ref pool[i], buffer, null ) == null )
{
break ; // found a null; swapped it in
}
}
}
// if no space, just drop it on the floor
buffer = null ;
}
}
刚开始看这代码感觉真的很怪，想为什么不用stack．．如果池经常为空的时候这样操作是很损耗效能．不过经过详细思考后发现其实这种设计如果当buffer占用到回收之间的时间很短那整个设计来看似乎很不错，池出现为空的情况很少基本只会自旋锁几下就可以了，这样做解决一些锁对象的开销；在密集处理情况效果应该不错，以上紧紧是过去设计经验判断的是不是真的还真要具体测验证．
有经验的朋友不知道对这样的设计有什么看法？
可靠、高性能的Socket TCP通讯组件
开源数据库访问组件
c#组件设计交流群：47164588
c# socket :136485198 微博http://weibo.com/ikende
作者： Leo_wl
出处： http://www.cnblogs.com/Leo_wl/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
版权信息