前言

Binder通信需要两个线程，这两个线程的优先级是不同，也就意味着，他们能获取到的cpu的优先级不同。

假如线程A通过非oneway的Binder调用到线程B，如果线程A的优先级大于线程B，这里就会有一个问题出现，线程A会因为线程B的优先级较低而block更多的时间。显然这是不合理的，Binder设计理念就是让你感觉不到IPC的存在，如同在同一线程中调用一个方法那么容易。

一、非oneway的Binder的流程

假设线程A通过Binder接口int add(a, b)将a和b发送给线程B，然后线程B计算c=a+b，将c返回给线程A。
简化一下步骤就是如图1.1

图1.1

二、如何将线程A优先级传递给线程B

我们先不看代码，自己想想如何实现这个需求。
我们可以考虑在a，b的数据包中带上线程A的优先级参数，
唤醒线程B的时候设置成A线程优先级，然后处理c=a+b，
处理完成之后然后发送c的数据给线程A，
发完之后，将线程B恢复成原来的线程优先级。
其实Binder驱动也就是这样子实现。简化一下步骤就是如图2.1

图2.1

三、代码分析

看了图2.1中的红色字体，你会发现整个实现很简单，有种将大象装进冰箱总共需要三步一样简单，我们就来分析每一步是如何实现的。

3.1 将线程A的优先级打包进a，b的数据包

对于非oneway的方法，会将client端线程A也就是current的policy和normal_prio值打包进binder_transaction t->priority

    struct binder_transaction *t;

    if (!(t->flags & TF_ONE_WAY) &&
        binder_supported_policy(current->policy)) {
        /* Inherit supported policies for synchronous transactions */
                //将client端线程也就是current的policy和normal_prio值打包进binder_transaction
        t->priority.sched_policy = current->policy;
        t->priority.prio = current->normal_prio;
    } else {
        /* Otherwise, fall back to the default priority */
        t->priority = target_proc->default_priority;
    }

3.2 唤醒线程B之后，保存线程B的优先级参数，并设置成线程A的优先级

从binder_transaction中获取线程A的优先级参数desired_prio
保存线程B的优先级参数到t->saved_priority
设置线程B的优先级参数为desired_prio。
注意：对于线程B返回给线程A的时候，不需要改变线程A的优先级

static int binder_thread_read(struct binder_proc *proc,
                  struct binder_thread *thread,
                  binder_uintptr_t binder_buffer, size_t size,
                  binder_size_t *consumed, int non_block)
{
....
        if (t->buffer->target_node) {
            struct binder_node *target_node = t->buffer->target_node;
            struct binder_priority node_prio;

            trd->target.ptr = target_node->ptr;
            trd->cookie =  target_node->cookie;
            node_prio.sched_policy = target_node->sched_policy;
            node_prio.prio = target_node->min_priority;
            //开始设置线程B的优先级
            binder_transaction_priority(current, t, node_prio,
                            target_node->inherit_rt);//跳转到3.2.1
            cmd = BR_TRANSACTION;
        } else { //对于server段返回给client端，不需要改变client端的线程优先级
            trd->target.ptr = 0;
            trd->cookie = 0;
            cmd = BR_REPLY;
        }
...
}

//3.2.1
static void binder_transaction_priority(struct task_struct *task,
                    struct binder_transaction *t,
                    struct binder_priority node_prio,
                    bool inherit_rt)
{
    //提取3.1保存的线程A的优先级，作为desired_prio
    struct binder_priority desired_prio = t->priority;
    //保存线程B的优先级到binder_transaction的saved_priority
    t->saved_priority.sched_policy = task->policy;
    t->saved_priority.prio = task->normal_prio;
        ...
    //设置线程B的优先级为desired_prio
    binder_set_priority(task, desired_prio);
}

3.3 恢复线程B的优先级

线程B返回结果的时候会调用这个代码
唤醒线程A
将线程B的优先级恢复

    if (reply) {
        ...
        //唤醒线程A
        wake_up_interruptible_sync(&target_thread->wait);
        //将线程B的优先级恢复
        binder_restore_priority(current, in_reply_to->saved_priority);
                ...
    } 

四、带着问题看源码

看了上面的代码，我们大概清楚了Binder驱动是如何解决IPC中两个线程优先级不同问题。
只能说是大概，希望大家带着以下问题去看源码，你会发现还有很多细节。

4.1 binder_supported_policy中支持的policy，以及不同policy的继承逻辑，线程的policy有几种

4.2 oneway的Binder调用中target_proc->default_priority是在哪里设置的

4.3 怎么最后恢复是in_reply_to->saved_priority，明明是线程B的优先级保存在 t->saved_priority，他们两者是同一个结构体吗？

4.4 HwBinder中对于线程优先级的继承是不是有更加丰富的逻辑。需要去看看HwBinder中IPCThreadState和普通的Binder的IPCThreadState的区别，以及在Binder驱动中对应的实现。

4.5 如果整个过程中出现了异常，是否会存在线程B无法恢复优先级的情况。

4.6 能否改造binder驱动，将cpuset的值继承给线程B。

五、尾巴

Binder真的是一个很有意思的东西，每一个微小的细节都是工程师的智慧，我们在研究Binder的时候更多要去学习他的设计思路，以后我们自己去开发类似的框架或者功能的时候也可以参考设计思路。今天我就抛砖引玉一下，这个玉还需要你们自己去挖掘。