进程间通信的经典实现
进程间通信(Inter-process communication,IPC)指运行在不同进程中的若干线程间的数据交换,可发生在一台机器上,也可通过网络跨机器实现。
共享内存、管道、UNIX Domain Socket 和 RPC 因高效稳定的优点几乎被应用在所有操作系统中。
共享内存
共享内存是一种常用的进程间通信机制,不同进程可以直接共享访问同一块内存区域,避免了数据拷贝,速度较快。实现步骤如下:
1. 创建内存共享区
Linux 通过 shmget 方法创建与特定 key 关联的共享内存块:
//返回共享内存块的唯一 Id 标识
int shmget(key_t key, size_t size, int shmflg);
2.映射内存共享区
Linux 通过 shmat 方法将某内存块与当前进程某内存地址映射:
//成功返回指向共享存储段的指针
void *shmat(int shm_id, const void *shm_addr, int shmflg);
3.访问内存共享区
其他进程要访问一个已存在的内存共享区的话,可以通过 key 调用 shmget 获取到共享内存块 Id,然后调用 shmat 方法映射。
4.进程间通信
当两个进程都实现对同一块内存共享区做映射后,就可以利用此内存共享区进行数据交换,但要自己实现同步机制。
5.撤销内存映射
进程间通信结束后,各个进程需要撤销之前的映射,Linux 可以调用 shmdt 方法撤销映射:
//成功则返回 0,否则出错
int shmdt(const void *shmaddr);
6.删除内存共享区
最后需要删除内存共享区,以便回收内存,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 操作:
- S = S - 1
- 然后判断若 S 大于等于 0,代表共享资源允许访问,进程继续执行
- 若 S 小于 0,代表共享资源被占用,需等待别人主动释放资源,该进程阻塞放入等待该信号量的队列中,等待被唤醒
V 操作:
- S = S + 1
- 然后判断若 S 大于 0,代表没有正在等待访问该资源的进程,无需处理
- 若 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 示例
我们熟知的 LinkedBlockingQueue,源码见 http://androidxref.com/7.0.0_r1/xref/frameworks/av/media/libstagefright/webm/LinkedBlockingQueue.h
class LinkedBlockingQueue {
List<T> 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 进程将得不到唤醒,尽管此队列中有元素。