ACE_Message_Block中的locking_strategy的使用
作者：海阔天空接着上一次的写。
先我们看看Ace_Message_Block中的locking_strategy锁到底作用在什么地方。
通过查看ACE的源代码，我们可以发现，在Ace_Message_Block中根本没有保存这把锁，而是直接传入内部的ACE_Data_Block中。在ACE_Data_Block中，保存了这把锁。ACE_Data_Block使用这把锁来控制duplicate和release时的同步。
可以这么说，如果你的程序中没有使用duplicate，那么，你在构造Ace_Message_Block的时候完全可以不用传递这个值，但如果你使用了duplicate，那么请一定加上这把锁。
由上面分析，我们可以认为，一个ACE_Data_Block对应着一把锁。实际上也应该这样理解，但是，ACE的作者却不是这么用的。
请看Ace_Message_Block的release和release_i()函数:
ACE_Message_Block * ACE_Message_Block::release (void)
ACE_Message_Block * ACE_Message_Block::release (void)
{
ACE_TRACE ("ACE_Message_Block::release");
// We want to hold the data block in a temporary variable because we
// invoked "delete this;" at some point, so using this->data_block_
// could be a bad idea.
ACE_Data_Block *tmp = this->data_block ();
// This flag is set to 1 when we have to destroy the data_block
int destroy_dblock = 0;
ACE_Lock *lock = 0;
// Do we have a valid data block
if (this->data_block ())
{
// Grab the lock that belongs to my data block
lock = this->data_block ()->locking_strategy ();
// if we have a lock
if (lock != 0)
{
// One guard for all
ACE_GUARD_RETURN (ACE_Lock, ace_mon, *lock, 0);
// Call non-guarded release with <lock>
destroy_dblock = this->release_i (lock);
}
// This is the case when we have a valid data block but no lock
else
// Call non-guarded release with no lock
destroy_dblock = this->release_i (0);
}
else
// This is the case when we don't even have a valid data block
destroy_dblock = this->release_i (0);
if (destroy_dblock != 0)
{
ACE_Allocator *allocator = tmp->data_block_allocator ();
ACE_DES_FREE (tmp,
allocator->free,
ACE_Data_Block);
}
return 0;
}
int ACE_Message_Block::release_i (ACE_Lock *lock)
{
ACE_TRACE ("ACE_Message_Block::release_i");
// Free up all the continuation messages.
if (this->cont_)
{
ACE_Message_Block *mb = this->cont_;
ACE_Message_Block *tmp = 0;
do
{
tmp = mb;
mb = mb->cont_;
tmp->cont_ = 0;
ACE_Data_Block *db = tmp->data_block ();
if (tmp->release_i (lock) != 0)
{
ACE_Allocator *allocator = db->data_block_allocator ();
ACE_DES_FREE (db,
allocator->free,
ACE_Data_Block);
}
}
while (mb);
this->cont_ = 0;
}
int result = 0;
if (ACE_BIT_DISABLED (this->flags_,
ACE_Message_Block::DONT_DELETE) &&
this->data_block ())
{
if (this->data_block ()->release_no_delete (lock) == 0)
result = 1;
this->data_block_ = 0;
}
// We will now commit suicide: this object *must* have come from the
// allocator given.
if (this->message_block_allocator_ == 0)
delete this;
else
{
ACE_Allocator *allocator = this->message_block_allocator_;
ACE_DES_FREE (this,
allocator->free,
ACE_Message_Block);
}
return result;
}
看出什么问题来了不？
如果你有两个或者两个以上的Message_Block用cont()连接起来。在调用release时，ACE会用第一的Message_Block的锁去释放后面的Message_Block。这样，如果这几个Message_Block不时用的同一把锁的话，在Release的时候就会出错。
分析了上面的问题，现在我们讨论一下Message-Block的优化。
首先.ACE_Data_Block中的锁的优化。
很多人使用的时候都是传入的一把锁给所有的ACE_Data_Block，结果每一个ACE_Message_Block，在duplicate 或者release的时候都需要获取这把锁。优化的方案就是为ACE_Data_Block都传一把锁进去，当然，在Release的时候就必须注意，不要直接调用ACE_Message_Block的Release函数。
其次ACE_Allocator的优化。
ACE_Allocator中有一把锁用于维持链表的线程安全。当你整个应用程序就只有一个ACE_Allocator时，每一个池中的对象在分配或者释放的时候都需要获取这把锁，那么线程之间的碰撞时很激烈的，解决的办法也很简单。在程序中每一个ACE_Allocator不要太大，相当于再做一个ACE_Allocator的池。 想问版主一个问题,如果牵涉到多结构体链表(或者数组)的传输,这样的锁会不会增加延迟呢?
比如说我设定一个内存区,当传输了800个相同结构体的数据时就将这些数据放到一个LIST对象模板中.这期间可能会收到其它程序发来的其它表结构体(帧头有表结构体类型标识)的数据,我只能暂存.这时如果使用Message_Block的话在锁的控制方面是不是和例子中一样呢? 文章是我转贴的，但其实只是提供了一个管理思路，我并不同意他的意见，因为这样违背了ACE_Message_Block的设计本意，如果不能方便的调用release()，会导致很多不便，甚至ACE内部框架都可能无法运行，因为很多框架之间都是用ACE_Message_Block粘合的。
要说对性能的影响,得看情况,如果你选择的锁策略是轻量级的,能够重入,而且对已经获得锁的线程的再次进入,不会造成问题,我认为其实不必考虑这个消耗,甚至可以把锁设置为NULL策略.
如果你采用的锁策略太重，就对性能有影响了。
看你的实际需要吧。 感觉这个锁用起来比校麻烦，因为常用的ACE_Thread_Mutex等都不是从其继承而来，所以得通过下面的方式转化来用
ACE_Lock_Adapter<ACE_Thread_Mutex> locker_;
还有切记上面的一句话 “ACE_Data_Block使用这把锁来控制duplicate和release时的同步”，这是有血的教训的 麻烦楼主讲一下这个locking_strategy怎么使用，给个使用例子吧
页:
[1]