持之以恒
分类: 网络与安全
2010-01-09 22:29:49
ACE_Message_Block是ACE中很重要的一个类,和ACE框架中的重要模式的实现 如ACE_Reactor, ACE_Proactor, ACE_Stream, ACE_Task都有紧密的联系.
换个角度看,ACE_Message_Block实际上已经是这些实现中的重要组成部分.抛开和框架的配合不谈, ACE_Message_Block本身也相当有用,功能强大,用途广泛.ACE_Message_Block的实现中使用了很多技巧和模式,代表性的有GOF的composite模式.这让它在处理数据特别是网络数据时会很方便.而且, 在多线程开发中,它也可以充当线程之间传递的消息.
ACE_Message_Block有几个重要特性:
1. ACE_Message_Block内部采用ACE_Data_Block来间接管理实际数据, 减轻了其它功能与实际内存管理之间的耦合.
2. ACE_Message_Block采用了引用计数, 可以灵活高效的共享数据, 并降低了内存拷贝带来的额外开销.
实际上, ACE_Message_Block本身并没有reference count, 而是间接的由ACE_Data_Block来提供.
3. 允许多条消息连接起来,形成一个单向链表, 从而支持复合消息Composite模式).
由此,ACE_Message_Block提供了cont()方法.
4. 允许将多条消息连接起来,形成一个双链表. 为ACE_Message_Queue的实现提供了支持.
由此,ACE_Message_Block提供next()和prev()方法.
5. 集成将同步策略和内存管理策略, 使得无需修改底层代码就能改变ACE_Message_Block的运行特征.
下面是自己总结的, 一开始总是混淆和迷惑的地方, 需要注意:
6. 3)4)特性实际上是正交的, 不存在交叉和冲突. 单链表实现复合消息, 双链表实现消息队列; 前者重内部, 后者重外部. 换个角度来说, 就是消息队列中的消息可以是复合消息.
7. ACE_Message_Block对内存空间的管理采用“谁申请谁释放”的策略.
在控制权转移时, 需要特别注意这一点.(空间的所有权可能会随size()方法的调用而转移)在使用外部的缓冲区构造ACE_Message_Block或者初始化时,需要特别注意.
前面已经说明, 处于减少耦合的原因,ACE_Message_Block并不直接管理实际数据,而是委托ACE_Data_Block进行管理.因此, 对ACE_Data_Block的很多函数都有包裹调用:如base(), end(), mark()等等.
虽然ACE_Data_Block的管理很高效,但是,总体来说ACE_Data_Block并不关注”数据的有效性”.ACE_Data_Block只是简单的对空间进行管理, 提供起始地址.就像一个普通buffer.
ACE_Message_Block弥补了ACE_Data_Block的不足, 提供了读指针和写指针(内部实现为游标). 这样,用户可以方便的进行连续读写,代表性的例子是ACE_Message_Block的copy()方法.也为多个ACE_Message_Block复用相同的ACE_Data_Block提供了良好的支持.
ACE_Data_Block有两种方式获取空间:
1) 自行申请空间
2) 使用用户提供的空间
如果没有设定DONT_DELETE标志, ACE_Data_Block还能自动替用户来释放所管理的空间.
当使用栈上的缓冲区初始ACE_Data_Block时,要特别注意保证缓冲区的有效性,防止ACE_Data_Block使用无效指针.
ACE_Message_Block提供了7个构造函数和3个初始化函数, 在实现中, 这些函数都不过是内部函数
init_i()函数的一个包裹.
init_i的参数有11个,不过大部分构造函数中调用时都设定了默认值.
参数 |
类型 |
用途说明 |
size |
size_t |
数据空间大小 |
type |
ACE_Message_Type |
消息类型 |
cont |
ACE_Message_Block * |
挂接其它MB以成为复合消息 |
data |
const char * |
data!=0 表示使用外部提供的空间 |
allocator_strategy |
ACE_Allocator * |
申请空间时, 使用的内存分配策略. data==0时使用. 默认值ACE_Allocator::instance() |
locking_strategy |
ACE_Lock * |
多线程下的安全策略 |
Message_Flags |
flags |
MB属性,用于判断是否要释放内部的ACE_Data_Block 当data!=0时,默认设置为DONT_DELETE |
priority |
unsigned long |
优先级,默认为0 |
excute_time |
const ACE_Time_Value& |
暂不使用 |
deadline_time |
const ACE_Time_Value& |
暂不使用 |
db |
ACE_Data_Block * |
使用外部提供的 |
data_block_allocator |
ACE_Allocator * |
ACE_Data_Block的分配策略. db==0时使用 默认值ACE_Allocator::instance() |
message_block_allocator |
ACE_Allocator * |
ACE_Message_Block的分配策略. 默认值ACE_Allocator::instance() |
默认的ACE_Allocator::instance()返回ACE_New_Allocator类型的策略.
实现动作很简单, 主要是旧data_block的释放和再申请,至于用户要求的size大小的空间,则交由ACE_Data_Block去具体负责.
ACE_Message_Block的在析构之外还单独具备了一个release()函数,各有用途,不能相互替代.
1) ACE_Message_Block的析构函数不关心单向链(复合消息)的处理,只是把自己本身清理干净.
2) release()是个递归函数, 它会通过cont()访问所有链接的ACE_Message_Block, 依次对其进行清理,然后最后清理自己本身.清理的方式是ACE_DES_FREE,类似于delete this,但不完全一样.
3) 还有一个静态的releas(ACE_Message_Block*)函数,功能是一样的
由此也可以看出,在栈上生成的ACE_Message_Block,千万不能调用release(),否则会发生所谓的”fall off the stack”.
ACE的注释:
析构函数很简单,主要是内部data_block的清理,注意是调用data_block()->release()
,因为ACE_Data_Block使用了引用计数.
这里省略了大部分线程策略处理,只保留了关键代码,可以看出,核心是release_i()函数.
ACE_Message_Block中有多个获取大小或者长度的函数,容易混淆.
下图是根据ACE_Message_Block(实际是ACE_Data_Block)空间的处理状况所绘,能比较清晰的反应出它们的异同.
需要注意,为了表现出多样性,下图是wr_ptr(),rd_ptr(),size()都调用过之后的情景.
红色表示是ACE_Message_Block独有的函数, 其余则ACE_Message_Block和ACE_Data_Block均有.
矩形纸上函数的返回值均为指针类型,之下的返回值均为size_t类型.
函数 |
说明 |
length() |
有效数据的长度 == wr_ptr() – rd_ptr() |
size() |
全部可用空间的长度,如果没有size()而变小,则等同capacity() == mark() – base() |
space() |
剩余可用空间的长度 <= size() - length(),因为不含rd_ptr()移动过的空间 == mark() – wr_ptr() |
capacity() |
最大空间的长度(ACE_Message_Block构造或初始化时所用参数值) == end() – base() |
total_length() |
复合消息(ACE_Message_Block内单向链 cont())的总长度 |
total_size() |
复合消息(ACE_Message_Block内单向链 cont())的总大小 |
total_capacity() |
复合消息(ACE_Message_Block内单向链 cont())的总空间大小 |
duplicate()浅拷贝函数,公用一个内部的ACE_Data_Block
ACE_Message_Block::duplicate() 与 ACE_Data_Block.duplicate()的实现是不同的.
ACE_Data_Block::duplicate()简单的只是将自身的reference加+1, 然后返回自身(this)
ACE_Message_Block:duplicate()则将自身copy了一份, 然后将自身的状态值赋给拷贝,注意它们公用同一个data_block.而且ACE_Message_Block::duplicate()支持复合消息,它会检查内部单向链,来依次调用其duplicate().
这里ACE_Data_Block::duplicate()的函数行为很怪异,以后就能看出它怪异行为的影响.说实话,这个地方如此设计我很不理解,因为ACE_Data_Block本身其实已经有reference了.
ACE_Message_Block::clone()深拷贝, 不但拷贝自身,内部的ACE_Data_Block也一并拷贝了,并且支持复合消息.
ACE_Data_Block.size(size_t len)函数, 动态的变化ACE_Data_Block持有的空间.
ACE_Message_Block.size(size_t len)函数是ACE_Data_Block.size(size_t len)的简单包裹.
如果len比现有的尺寸小, 简单的cur_size_ = length;
如果len比现有的尺寸大, 会申请新的空间并拷贝原所有数据.
注意! 这里可能会发生空间控制权的转换! 即标志位DONT_DELETE的变化.若原ACE_Data_Block使用托管空间, 则此时会更替为自己申请的空间,从而拥有了控制权, 所以此时要注意原有空间的管理.
对ACE_Message_Block和ACE_Data_Block, 除非主动调用size(), 否则它们不会自动申请和扩大空间.
ACE_Message_Block::crunch() 将现有数据移动到现有的缓冲的开始.
ACE_Message_Block::reset()将现有读写指针赋为初始值(ACE_Data_Block.base())
ACE_Message_Block::base()是对ACE_Data_Block.base()的简单包裹
1)ACE_Message_Block的构造函数中,如果data为NULL, 则ACE_Message_Block会为其自动分配空间. 但如data非NULL,则ACE_Message_Block会直接引用data指向的空间, 并不会进行新的空间分配和拷贝.
所以需要特别注意, 在ACE_Message_Block的实例没有销毁之前,不能释放data指向的空间.
2)虽然ACE_Message_Block会根据size的值来更改自己的size(),但wr_ptr不会根据data的长度进行设置, 造成length()的返回为0.
需要特别注意, 当构造一个ACE_Message_Block实例后, 随之需要追加数据时,必须设置wr_ptr的值,否则原有数据将会被覆写.
此时的含义是: ACE_Message_Block代管了data缓冲区,但不负责缓冲区的空间管理(因为也不是由它申请的).
默认定义的flag: enum { = 01, = 0x1000 }
1) set_flags()、clr_flags()是对ACE_Message_Block中的数据指针(ACE_Data_Block*)进行设置.
2) set_self_flags(),clr_self_flags()是对ACE_Message_Block本身进行设置.
ACE_Message_Block::copy(const char* buf) 函数将字符串copy到ACE_Message_Block, 如果内在空间不足, 将会返回-1.
需要特别注意, copy的数据将包括末尾的0, 也就是copy的数据长度为strlen(buf)+1.
而且, 会自动进行wr_ptr()的设置
ACE_Data_Block的析构函数是释放持有空间base_的惟一路径(size()的情况不讨论).
ACE_Data_Block中通过duplicate()递增引用计数. ACE_Data_Block中通过release()递减引用计数, 当引用计数为0时,先调用ACE_Data_Block析构函数,然后释放ACE_Data_Block自身.
注意, ACE_Data_Block的构造和析构函数都不知道引用计数的存在. 在构造函数中, 只是设置了初始值1.
ACE_Data_Block一个很奇怪的地方就是ACE_Data_Block::duplicate()的实现, 并没有创建新的拷贝, 而仅仅是返回了自身(return this). 这中实现方式带来了很多奇怪的问题.如下面的2,3.
release()-> release_no_delete()->release_i()->~ACE_Data_Block()
如果在Stack上构造ACE_Data_Block,那么不能使用release()函数, 因为release()函数会试图删除this
如果在stack上构造ACE_Data_Block, 那么不能使用duplicate()函数, 因为duplicate()返回的是this指针, 栈中的ACE_Data_Block析构后会导致问题.
如果在heap上构造ACE_Data_Block,那么尽量使用release()来替代delete, 如果存在因为析构并不处理reference count, delete时不考虑其它会导致指针悬空.