细读《深入理解 Android 内核设计思想》(一)进程间通信与同步机制

对冗余挑拣重点,对重点深入补充,输出结构清晰的精简版

1.进程间通信的经典实现
共享内存、管道
UNIX Domain Socket
Remote Procedure Calls
2.同步机制的经典实现
信号量、Mutex、管程、Linux Futex
3.Android 中的进程间同步机制
Mutex、Condition、Autolock
Mutex+Autolock+Condition 示例
4.最后

进程间通信的经典实现

进程间通信(Inter-process communication,IPC)指运行在不同进程中的若干线程间的数据交换,可发生在同一台机器上,也可通过网络跨机器实现,以下几种因高效稳定的优点几乎被应用在所有操作系统中,分别是共享内存、管道、UNIX Domain Socket 和 RPC 。

共享内存

共享内存是一种常用的进程间通信机制,不同进程可以直接共享访问同一块内存区域,避免了数据拷贝,速度较快。实现步骤:

  1. 创建内存共享区
    Linux 通过 shmget 方法创建与特定 key 关联的共享内存块:
//返回共享内存块的唯一 Id 标识
int shmget(key_t key, size_t size, int shmflg);               
  1. 映射内存共享区
    Linux 通过 shmat 方法将某内存块与当前进程某内存地址映射
//成功返回指向共享存储段的指针 
void *shmat(int shm_id, const void *shm_addr, int shmflg);        
  1. 访问内存共享区
    其他进程要访问一个已存在的内存共享区的话,可以通过 key 调用 shmget 获取到共享内存块 Id,然后调用 shmat 方法映射
  2. 进程间通信
    当两个进程都实现对同一块内存共享区做映射后,就可以利用此内存共享区进行数据交换,但要自己实现同步机制
  3. 撤销内存映射
    进程间通信结束后,各个进程需要撤销之前的映射,Linux 可以调用 shmdt 方法撤销映射:
//成功则返回 0,否则出错
int shmdt(const void *shmaddr);
  1. 删除内存共享区
    最后需要删除内存共享区,以便回收内存,Linux 可以调用 shctl 进行删除:
//成功则返回 0,否则出错,删除操作 cmd 需传 IPC_RMID
int shmctl(int shm_id, int cmd, struct shmid_ds *buf);

shmget 方法名言简意赅,share memory get !其中 get 还有一层含义,为什么不叫 create 呢?之前如果创建过某一 key 的共享内存块,再次调用便直接返回该内存块,不会发生创建操作了。

管道

管道(Pipe)是操作系统中常见的一种进程间通信方式,一根管道有"读取"和"写入"两端,读、写操作和普通文件操作类似,并且是单向的。管道有容量限制,当写满时,写操作会被阻塞;为空时读操作会被阻塞。

Linux 通过 pipe 方法打开一个管道:

//pipe_fd[0] 代表读端,pipe_fd[1] 代表写端,
int pipe(int pipe_fd[2], int flags);

以上方式只能用于父子进程,因为只有一个进程中定义的 pipe_fd 文件描述符只有通过 fork 方式才能传给另一个进程继承获取到,也正是因为这个限制,Named Pipe 得以发展,改变了前者匿名管道的方式,可以在没有任何关系的两个进程间使用。

UNIX Domain Socket

UNIX Domain Socket(UDS)是专门针对单机内的进程间通信,也称 IPC Socket,与 Network Socket 使用方法基本一致,但实现原理区别很大:

  • Network Socket 基于 TCP/IP 协议,通过 IP 地址或端口号进行跨进程通信
  • UDS 基于本机 socket 文件,不需要经过网络协议栈,不需要打包拆包、计算校验等

Android 中使用最多的 IPC 是 Binder,其次就是 UDS。

Remote Procedure Calls

RPC 即远程过程调用(Remote Procedure Call),RPC 是指计算机 A 上的进程,调用另外一台计算机 B 上的进程,其中 A 上的调用进程被挂起,而 B 上的被调用进程开始执行,当值返回给 A 时,A 进程继续执行。调用方可以通过使用参数将信息传送给被调用方,而后可以通过传回的结果得到信息。

Java RMI 就是一种 RPC 框架,指的是远程方法调用 (Remote Method Invocation)。它能够让一个 Java 虚拟机上的对象调用另一个 Java 虚拟机中的对象的方法。

RPC 可以理解为一种编程模型,就像 IPC 一样,比如我们常说 Android AIDL 是一种 IPC 实现方式,也可以称为一种 RPC 方式。

同步机制的经典实现

信号量

信号量与 PV 原语操作是一种广泛使用的实现进程/线程互斥与同步的有效方法,Semaphore S 信号量用于指示共享资源的可用数量。
P 操作:

  1. S = S - 1
  2. 然后判断若 S 大于等于 0,代表共享资源允许访问,进程继续执行
  3. 若 S 小于 0,代表共享资源被占用,需等待别人主动释放资源,该进程阻塞放入等待该信号量的队列中,等待被唤醒

V 操作:

  1. S = S + 1
  2. 然后判断若 S 大于 0,代表没有正在等待访问该资源的进程,无需处理
  3. 若 S 小于等于 0,从该信号的等待队列中唤醒一个进程

Java 中的信号量的实现类为 Semaphore,P、V 操作分别对应 acquire、release 方法。

Mutex

Mutex 即互斥锁,可以和信号量对比来理解,信号量可以使资源同时被多个线程访问,而互斥锁同时只能被一个线程访问,也就是说,互斥锁相当于一个只允许取值 0 或 1 的信号量。

Java 中 ReentrantLock 就是互斥锁的一种实现。

管程

采用 Semaphore 机制的程序中 P、V 操作大量分散在程序中,代码易读性差,不易管理,容易发生死锁,所以引入了管程 Monitor。

管程把分散在各进程中的临界区集中起来进行管理,防止进程有意或无意的违法同步操作,便于用高级语言来书写程序,也便于程序正确性验证。

管程封装了同步操作,对进程隐蔽了同步细节,简化了同步功能的调用界面。用户编写并发程序如同编写顺序(串行)程序。

Java 中 synchronized 同步代码块就是 Monitor 的一种实现。

Linux Futex

Futex 全称 Fast Userspace muTexes,直译为快速用户空间互斥体,那他比普通的 Mutex 快在哪里呢?

Semaphore 等传统同步机制需要从用户态进入到内核态,通过一个提供了共享状态信息和原子操作的内核对象来完成同步。但大多数场景同步是无竞争的,不需要进入互斥区等待就可以直接获取到锁,但依然进行了内核态的切换操作,这造成了大量的性能开销。

Futex 通过 mmap 让进程间共享一段内存,当进程尝试进入互斥区或退出互斥区的时候,先查看共享内存中的 Futex 变量,如果没有竞争发生,则只修改 Futex 变量而不执行系统调用切换内核态。

Futex 的 Fast 就体现在对于大多数不存在竞争的情况,可以在用户态就完成锁的获取,而不需要进入内核态,从而提高了效率。

如果说 Semaphore 等传统同步机制是一种内核态同步机制,那 Futex 就是一种用户态和内核态混合的同步机制。

Futex 在 Android 中的一个重要应用场景是 ART 虚拟机,如果 Android 版本开启了 ART_USE_FUTEXES 宏,那 ART 虚拟机中的同步机制就会以 Futex 为基石来实现,省略后的关键代码如下:

// art/runtime/base/mutex.cc
void Mutex::ExclusiveLock(Thread* self){
    #if ART_USE_FUTEXES
        //若开启 Futex 宏就通过 Futex 实现互斥加锁
        futex(...) 
    #else
        //否则通过传统 pthread 实现
        CHECK_MUTEX_CALL(pthread_mutex_lock,(&mutex_));
}

源码见 http://androidxref.com/7.0.0_r1/xref/art/runtime/base/mutex.cc

Android 中的进程间同步机制

了解了操作系统经典的同步机制后,再来看 Android 中是怎么实现的。

进程间同步 Mutex

Mutex 实现类源码很短,见 http://androidxref.com/7.0.0_r1/xref/system/core/include/utils/Mutex.h

注意这里说的 Mutex 和上面的 mutex.cc 是两个东西,mutex.cc 是 ART 中的实现类,支持 Futex 方式; 而 Mutex.h 只是对 pthread 的 API 进行了简单封装,函数声明和实现都在 Mutex.h 一个文件中。

源码中可以看到一个枚举类型定义:

class Mutex {
public:
    enum {
        PRIVATE = 0,
        SHARED = 1
    };

其中 PRIVATE 代表进程内同步,SHARED 代表进程间同步。Mutex 相比 Semaphore 较简单,只有 0 和 1 两种状态,关键方法为:

inline status_t Mutex::lock() {//获取资源锁,可能阻塞等待
    return -pthread_mutex_lock(&mMutex);
}
inline void Mutex::unlock() {//释放资源锁
    pthread_mutex_unlock(&mMutex);
}
inline status_t Mutex::tryLock() {//获取资源锁,不论成功与否都立即返回
    return -pthread_mutex_trylock(&mMutex);
}

当要访问临界资源时,需先通过 lock() 获得资源锁,如果资源可用会此函数会立即返回,否则阻塞等待,直到其他进程(线程)调用 unlock() 释放了资源锁从而被唤醒。

tryLock() 函数存在有什么意义呢?它在资源被占用的情况下,不会像 lock() 一样进入等待,而是立即返回,所以可以用来试探性查询资源锁是否被占用。

加解锁的自动化操作 Autolock

Autolock 为 Mutex.h 中的一个嵌套类,实现如下:

// Manages the mutex automatically. It'll be locked when Autolock is
// constructed and released when Autolock goes out of scope.
class Autolock {
public:
    inline Autolock(Mutex& mutex) : mLock(mutex)  { mLock.lock(); }
    inline Autolock(Mutex* mutex) : mLock(*mutex) { mLock.lock(); }
    inline ~Autolock() { mLock.unlock(); }
private:
    Mutex& mLock;
};

如注释所示,Autolock 会在构造时主动去获取锁,在析构时会自动释放掉锁,也就是说,在生命周期结束时会自动把资源锁释放掉。

这就可以在一个方法开始时为某 Mutex 构造一个 Autolock,当方法执行完后此锁会自动释放,无需再主动调用 unlock,这让 lock/unlock 的配套使用更加简便,不易出错,

条件判断 Condition

条件判断的核心思想是判断某 "条件" 是否满足,满足的话马上返回,否则阻塞等待,直到条件满足时被唤醒。

你可能会疑问,Mutex 不就可以实现吗,干嘛又来一个 Condition,它有什么特别之处?

Mutex 确实可以实现基于条件判断的同步,假如条件是 a 为 0,实现代码会是这样:

while(1){
  acquire_mutex_lock(a); //获取 a 的互斥锁
  if(a==0){
    release_mutex_lock(a); //释放锁
    break; //条件满足,退出死循环
  }else{
    release_mutex_lock(a); //释放锁
    sleep();//休眠一段时间后继续循环
  }
}

什么时候满足 a==0 是未知的,可能是很久之后,但上面方式无限循环去判断条件,极大浪费 CPU。

而条件判断不需要死循环,可以在满足条件时才去通知唤醒等待者。

Condition 源码见 http://androidxref.com/7.0.0_r1/xref/system/core/include/utils/Condition.h ,它和 Mutex 一样也有 PRIVATE、SHARED 类型,PRIVATE 代表进程内同步,SHARED 为进程间同步。关键方法为:

//在某个条件上等待
status_t wait(Mutex& mutex)
//在某个条件上等待,增加超时机制
status_t waitRelative(Mutex& mutex, nsecs_t reltime)
//条件满足时通知相应等待者
void signal()
//条件满足时通知所有等待者
void broadcast()

Mutex+Autolock+Condition 示例

书中通过 Barrier 呈现 Condition 使用示例,还有一个我们更为熟知的 LinkedBlockingQueue 也很适合,源码见 http://androidxref.com/7.0.0_r1/xref/frameworks/av/media/libstagefright/webm/LinkedBlockingQueue.h。

class LinkedBlockingQueue {
    List mList;
    Mutex mLock;
    Condition mContentAvailableCondition;

    T front(bool remove) {
        Mutex::Autolock autolock(mLock);
        while (mList.empty()) {
            mContentAvailableCondition.wait(mLock);
        }
        T e = *(mList.begin());
        if (remove) {
            mList.erase(mList.begin());
        }
        return e;
    }
    //省略...

    void push(T e) {
        Mutex::Autolock autolock(mLock);
        mList.push_back(e);
        mContentAvailableCondition.signal();
    }
}

调用 front 方法出队元素时,首先获取 mLock 锁,然后判断若列表为空就调用 wait 方法进入等待状态,待 push 方法入队元素后通过 signal 方法唤醒。

front 方法占有了 mLock 锁,push 方法不应该阻塞在第一行代码无法往下执行吗?

很简单,wait 方法中释放了 mLock 锁,见 pthread_cond.cpp:http://androidxref.com/7.0.0_r1/xref/bionic/libc/bionic/pthread_cond.cpp#173

可以不依赖 Mutex 仅通过 Condition 的 wait/signal 实现吗?

不行,因为对 mList 的访问需要加互斥锁,否则可能出现 signal 无效的情况。比如 A 进程调用 front ,判断 mList 为空,即将执行 wait 方法时,B 进程调用 push 方法并执行完,那么 A 进程将得不到唤醒,尽管此队列中有元素。

最后

书中说到:不论什么样的操作系统,其技术本质都类似,而更多的是把这些核心的理论应用到符合自己需求的场景中。

不知道在讲这句话时,作者脑中一闪而过的,是怎样庞大而深厚的技术栈。

链接:细读《深入理解 Android 内核设计思想》系列

你可能感兴趣的:(细读《深入理解 Android 内核设计思想》(一)进程间通信与同步机制)