8.6.1 Surface系统的CB对象分析
最后更新于：2022-04-02 05:52:56
根据前文分析可知，Surface系统中的CB，其实是指SharedBuffer家族，它们是Surface系统中对生产者和消费者进行步调控制的中枢机构。先通过图8-24来观察整体的工作流程是怎样的。
:-: 
图8-24 SharedBuffer家族使用流程
为书写方便起见，我们简称：
- SharedBufferServer为SBS。
- SharedBufferClient为SBC。
- SharedBufferStack为SBT。
其中SBC和SBS都是建立在同一个SBT上的，所以应先看SBT，下面代码列出了其中几个与读写控制有关的成员变量：
**SharedBufferStack.h**
~~~
class SharedBufferStack{
......
/*
虽然PageFlipping使用Front和Back两个Buffer就可以了，但是SBT的结构和相关算法
是支持多个缓冲的。另外，缓冲是按照块来获取的，也就是一次获得一块缓冲，每块缓冲用
一个编号表示（这一点在之前的分析已经介绍过了）。
*/
int32_t head;
int32_tavailable; //当前可用的空闲缓冲个数
int32_t queued; //SBC投递的脏缓冲个数
int32_tinUse; //SBS当前正在使用的缓冲编号
......//上面这几个参数联合SBC中的tail，我称之为控制参数。
}
~~~
SBT创建好后，下面就是SBS和SBC的创建了，它们会做什么特殊工作吗？
1. SBS和SBC的创建
下面分别看SBS和SBC的创建，代码如下所示：
**SharedBufferStack.cpp**
~~~
SharedBufferServer::SharedBufferServer(SharedClient*sharedClient,
int surface, int num, int32_t identity)
:SharedBufferBase(sharedClient, surface, num, identity)
{
mSharedStack->init(identity);//这个函数将设置inUse为-1
//下面设置SBT中的参数，我们关注前三个
mSharedStack->head = num-1;
mSharedStack->available = num;
mSharedStack->queued = 0;
//设置完后，head=2-1=1,available=2,queued=0，inUse=-1
mSharedStack->reallocMask = 0;
memset(mSharedStack->dirtyRegion, 0,sizeof(mSharedStack->dirtyRegion));
}
~~~
再看SBC的创建，代码如下所示：
**SharedBufferStack.cpp**
~~~
SharedBufferClient::SharedBufferClient(SharedClient*sharedClient,
int surface, int num, int32_t identity)
:SharedBufferBase(sharedClient, surface, num, identity), tail(0)
{
tail =computeTail(); //tail是SBC定义的变量，注意它不是SBT定义的。
}
~~~
看computeTail函数的代码：
**SharedBufferStack.cpp**
~~~
int32_t SharedBufferClient::computeTail() const
{
SharedBufferStack& stack( *mSharedStack );
int32_t newTail;
int32_t avail;
int32_t head;
do {
avail = stack.available; //available=2,head=1
head = stack.head;
}while (stack.available != avail);
newTail = head - avail + 1;//newTail=1-2+1=0
if(newTail < 0) {
newTail += mNumBuffers;
} elseif (newTail >= mNumBuffers) {
newTail -= mNumBuffers;
}
return newTail;//计算得到newTail=0
}
~~~
来看在SBC和SBS创建后，控制参数的变化，如图8-25所示：
:-: 
图8-25 SBC/SBS创建后的示意图
2. SBC端流程的分析
下面看SBC端的工作流程。
（1）dequeue分析
先看SBC的dequeue函数：
**SharedBufferStack.cpp**
~~~
ssize_t SharedBufferClient::dequeue()
{
SharedBufferStack& stack( *mSharedStack );
......
//DequeueCondition函数对象
DequeueCondition condition(this);
status_t err = waitForCondition(condition);
//成功以后，available减1，表示当前可用的空闲buffer只有1个
if (android_atomic_dec(&stack.available) == 0) {
......
}
int dequeued = tail; //tail值为0，所以dequeued的值为0。
//tail加1。如果超过2，则重新置为0，这表明tail的值在0,1间循环。
tail =((tail+1 >= mNumBuffers) ? 0 : tail+1);
......
//返回的这个dequeued值为零，也就是tail加1操作前的旧值。这一点请读者务必注意。
returndequeued;
}
~~~
其中DequeueCondition的操作函数很简单，代码如下所示：
~~~
bool SharedBufferClient::DequeueCondition::operator()(){
returnstack.available > 0;//只要available大于0就算满足条件，第一次进来肯定满足
}
~~~
用图8-26来表示dequeue的结果：
:-: 
图8-26 dequeue结果图
注意，在上图中，0号缓冲用虚线表示，SBC的dequeue函数的返回值用dequeued表示，它指向这个0号缓冲。正如代码中注释的那样，由于dequeued的值用的是tail的旧值，而tail是SBC定义的变量，不是SBT定义的变量，所以tail在SBS端是不可见的。这就带来了一个潜在危险，即0号缓冲不能保证当前是真正空闲的，因为SBS可能正在用它，怎么办？试看下面的lock。
（2）lock的分析
lock使用了LockCondition，其中传入的参数buf的值为0，也就是上图中的dequeue的值，代码如下所示：
**SharedBufferStack.cpp**
~~~
status_t SharedBufferClient::lock(int buf)
{
LockCondition condition(this, buf);
status_terr = waitForCondition(condition);
returnerr;
}
~~~
看LockCondition的()函数：
~~~
boolSharedBufferClient::LockCondition::operator()() {
/*
这个条件其实就是判断编号为buf的Buffer是不是被使用了。
buf值为0，head值为1，queued为0，inUse为-1
*/
return(buf != stack.head ||
(stack.queued > 0 && stack.inUse!= buf));
}
~~~
现在可以知道为什么SBC需要调用dequeue和lock函数了吗？原来：
- dequeue只是根据本地变量tail计算一个本次应当使用的Buffer编号，其实也就是在0,1之间循环。上次用0号缓冲，那么这次就用1号缓冲。
- lock函数要确保这个编号的Buffer没有被SF当做FrontBuffer使用。
（3）queue的分析
Activity端在绘制完UI后，将把BackBuffer投递出去以显示。接着上面的流程，这个BackBuffer的编号是0。待Activity投递完后，才会调用signal函数触发SF消费，所以在此之前格局不会发生变化。试看投递用的queue函数，注意传入的buf参数为0，代码如下所示：
**SharedBufferStack.cpp**
~~~
status_t SharedBufferClient::queue(int buf)
{
QueueUpdate update(this);
status_t err = updateCondition( update );
......
returnerr;
}
//直接看这个QueueUpdate函数对象
ssize_tSharedBufferClient::QueueUpdate::operator()() {
android_atomic_inc(&stack.queued);//queued增加1，现在该值由零变为1
returnNO_ERROR;
}
~~~
至此，SBC端走完一个流程了，结果是什么？如图8-27所示：
:-: 
图8-27 queue结果图
0号缓冲被移到queue的区域了，可目前还没有变量指向它。假设SBC端此后没有绘制UI的需求，那么它就会沉默一段时间。
3. SBS端的分析
SBS的第一个函数是retireAndLock，它使用了RetireUpdate函数对象，代码如下所示：
**SharedBufferStack.cpp**
~~~
ssize_t SharedBufferServer::retireAndLock()
{
RetireUpdate update(this, mNumBuffers);
ssize_t buf = updateCondition( update );
returnbuf;
}
~~~
这个RetireUpdate对象的代码如下所示：
~~~
ssize_tSharedBufferServer::RetireUpdate::operator()() {
//先取得head值，为1
int32_t head = stack.head;
//inUse被设置为1。表明要使用1吗？目前的脏缓冲应该是0才对
android_atomic_write(head, &stack.inUse);
int32_tqueued;
do {
queued = stack.queued; //queued目前为1
if(queued == 0) {
return NOT_ENOUGH_DATA;
}
//下面这个原子操作使得stack.queued减1.
}while (android_atomic_cmpxchg(queued, queued-1, &stack.queued));
//while循环退出后，queued减1，又变为0。
//head值也在0,1间循环，现在head值变为0了
head =((head+1 >= numBuffers) ? 0 : head+1);
//inUse被设置为0
android_atomic_write(head, &stack.inUse);
// head值被设为0
android_atomic_write(head, &stack.head);
// available加1，变成2.
android_atomic_inc(&stack.available);
returnhead;//返回0
}
~~~
retireAndLock的结果是什么呢？看看图8-28就知道了。
:-: 
图8-28 retireAndLock结果图
注意上面的available区域，1号缓冲右边的0号缓冲是用虚线表示的，这表示该0号缓冲实际上并不存在于available区域，但available的个数却变成2了。这样不会出错吗？当然不会，因为SBC的lock函数要确保这个缓冲没有被SBS使用。
我们来看SBS端最后一个函数，它调用了SBS的unlock，这个unlock使用了UnlockUpdate函数对象，就直接了解它好了，代码如下所示：
**SharedBufferStack.cpp**
~~~
ssize_tSharedBufferServer::UnlockUpdate::operator()() {
......
android_atomic_write(-1, &stack.inUse);//inUse被设置为-1
returnNO_ERROR;
}
~~~
unlock后最终的结果是什么呢？如图8-29所示：
:-: 
图8-29 unlock结果图
比较一下图8-29和图8-25，可能会发现两图中tail和head刚好反了，这就是PageFlip。另外，上面的函数大量使用了原子操作。原子操作的目的就是为了避免锁的使用。值得指出的是，updateConditon函数和waitForCondition函数都使用了Mutex，也就是说，上面这些函数对象又都是在Mutex锁的保护下执行的，为什么会这样呢？先来看一段代码：
~~~
像下面这样的代码，如果有锁控制的话根本用不着一个while循环，因为有锁的保护，没有其他线程
能够修改stack.queued的值，所以用while来循环判断android_atomic_cmpxchg没有什么意义。
int32_tqueued;
do {
queued = stack.queued;
if(queued == 0) {
return NOT_ENOUGH_DATA;
}
}while (android_atomic_cmpxchg(queued, queued-1, &stack.queued));
~~~
对于上面这个问题，我目前还不知道答案，但对其也进行了修改，把函数对象放在锁外执行，结果在真机上运行没有出现任何异常现象。也许Google或哪位读者能给这个问题一个较好的解释。
为什么我对生产/消费的同步控制如此感兴趣呢？这和自己工作的经历有些关系。因为之前曾做过一个单写多读的跨进程缓冲类，也就是一个生产者，多个消费者。为了保证正确性和一定的效率，我们在算法上曾做了很多改进，但还是大量使用了锁，所以我很好奇Google是怎么做到的，这也体现了一个高手的内功修养。要是由读者自己来实现，结果会怎样呢？
';