在Android中，封装的同步类主要有Mutex（AutoMutex）与Condition。
这两个类在android中被大量的使用，这也说明这两个类是非常重要的。
一、Mutex（AutoMutex）与Condition代码分析
1.1 Mutex（AutoMutex）代码分析
Mutex是互斥类，用于多线程访问同一个资源的时候，保证一次只有一个线程能访问该资源。
system/core/include/utils/Mutex.h
#ifndef _LIBS_UTILS_MUTEX_H
#define _LIBS_UTILS_MUTEX_H
#include <stdint.h>
#include <sys/types.h>
#include <time.h>
#if !defined(_WIN32)
# include <pthread.h>
#endif
#include <utils/Errors.h>
#include <utils/Timers.h>
// Enable thread safety attributes only with clang.
// The attributes can be safely erased when compiling with other compilers.
#if defined(__clang__) && (!defined(SWIG))
#define THREAD_ANNOTATION_ATTRIBUTE__(x) __attribute__((x))
#else
#define THREAD_ANNOTATION_ATTRIBUTE__(x) // no-op
#endif
#define CAPABILITY(x) THREAD_ANNOTATION_ATTRIBUTE__(capability(x))
#define SCOPED_CAPABILITY THREAD_ANNOTATION_ATTRIBUTE__(scoped_lockable)
#define GUARDED_BY(x) THREAD_ANNOTATION_ATTRIBUTE__(guarded_by(x))
#define PT_GUARDED_BY(x) THREAD_ANNOTATION_ATTRIBUTE__(pt_guarded_by(x))
#define ACQUIRED_BEFORE(...) THREAD_ANNOTATION_ATTRIBUTE__(acquired_before(__VA_ARGS__))
#define ACQUIRED_AFTER(...) THREAD_ANNOTATION_ATTRIBUTE__(acquired_after(__VA_ARGS__))
#define REQUIRES(...) THREAD_ANNOTATION_ATTRIBUTE__(requires_capability(__VA_ARGS__))
#define REQUIRES_SHARED(...) THREAD_ANNOTATION_ATTRIBUTE__(requires_shared_capability(__VA_ARGS__))
#define ACQUIRE(...) THREAD_ANNOTATION_ATTRIBUTE__(acquire_capability(__VA_ARGS__))
#define ACQUIRE_SHARED(...) THREAD_ANNOTATION_ATTRIBUTE__(acquire_shared_capability(__VA_ARGS__))
#define RELEASE(...) THREAD_ANNOTATION_ATTRIBUTE__(release_capability(__VA_ARGS__))
#define RELEASE_SHARED(...) THREAD_ANNOTATION_ATTRIBUTE__(release_shared_capability(__VA_ARGS__))
#define TRY_ACQUIRE(...) THREAD_ANNOTATION_ATTRIBUTE__(try_acquire_capability(__VA_ARGS__))
#define TRY_ACQUIRE_SHARED(...) \
THREAD_ANNOTATION_ATTRIBUTE__(try_acquire_shared_capability(__VA_ARGS__))
#define EXCLUDES(...) THREAD_ANNOTATION_ATTRIBUTE__(locks_excluded(__VA_ARGS__))
#define ASSERT_CAPABILITY(x) THREAD_ANNOTATION_ATTRIBUTE__(assert_capability(x))
#define ASSERT_SHARED_CAPABILITY(x) THREAD_ANNOTATION_ATTRIBUTE__(assert_shared_capability(x))
#define RETURN_CAPABILITY(x) THREAD_ANNOTATION_ATTRIBUTE__(lock_returned(x))
#define NO_THREAD_SAFETY_ANALYSIS THREAD_ANNOTATION_ATTRIBUTE__(no_thread_safety_analysis)
// ---------------------------------------------------------------------------
namespace android {
// ---------------------------------------------------------------------------
class Condition;
/*
* NOTE: This class is for code that builds on Win32. Its usage is
* deprecated for code which doesn't build for Win32. New code which
* doesn't build for Win32 should use std::mutex and std::lock_guard instead.
*
* Simple mutex class. The implementation is system-dependent.
*
* The mutex must be unlocked by the thread that locked it. They are not
* recursive, i.e. the same thread can't lock it multiple times.
*/
class CAPABILITY("mutex") Mutex {
public:
//两种类型：PRIVATE是进程内部使用的；SHARED是适用于跨进程共享的。
//如不指定，缺省是PRIVATE的类型。
enum {
PRIVATE = 0,
SHARED = 1
};
Mutex();//构造函数
explicit Mutex(const char* name);//构造函数
explicit Mutex(int type, const char* name = nullptr);//构造函数,type就是上面的那两种类型
~Mutex();//析构函数
// lock or unlock the mutex
status_t lock() ACQUIRE();//获取锁。如果获取就返回，否则挂起等待
void unlock() RELEASE();//释放锁
// lock if possible; returns 0 on success, error otherwise
//如果当前锁可被获取（未被别的线程获取）就lock，否则就直接返回。
//返回值：0代表成功；其它值失败。
//与lock()的区别在于不论成功与否都会及时返回，而不是挂起等待。
status_t tryLock() TRY_ACQUIRE(0);
#if defined(__ANDROID__)
// Lock the mutex, but don't wait longer than timeoutNs (relative time).
// Returns 0 on success, TIMED_OUT for failure due to timeout expiration.
//
// OSX doesn't have pthread_mutex_timedlock() or equivalent. To keep
// capabilities consistent across host OSes, this method is only available
// when building Android binaries.
//
// FIXME?: pthread_mutex_timedlock is based on CLOCK_REALTIME,
// which is subject to NTP adjustments, and includes time during suspend,
// so a timeout may occur even though no processes could run.
// Not holding a partial wakelock may lead to a system suspend.
status_t timedLock(nsecs_t timeoutNs) TRY_ACQUIRE(0);
#endif
// Manages the mutex automatically. It'll be locked when Autolock is
// constructed and released when Autolock goes out of scope.
//Autolock是为了简化Mutex的使用而定义的,并且充分利用了c++的构造与析构机制
//可以看出，在构造函数中mLock.lock()加锁，在析构函数中mLock.unlock() 解锁。
//所以，对一个需要加锁的函数来说，我们只需要在函数开始处，声明这样 (Mutex::Autolock autolock(mLock);)，一个变量，它就会加锁，
//等函数退出时，这样一个临时变量就会析构，就会解锁。
//android系统里几乎到处都是这种使用，或者AutoMutex _l(mLock)这种使用
//这两种使用是一样的效果的，因为下面有这样一行代码typedefMutex::Autolock AutoMutex;
//这种设计师非常优秀的，如果你手动去lock，unlock，就有可能忘了unlock,这样的会很容易死锁，死锁在android系统里后果是非常严重，大多数情况都会系统重启
//大家都知道C++的构造函数析构函数是成对出现的，用了构造函数中mLock.lock()加锁，
//在析构函数中mLock.unlock()解锁这种设计之后，就不会出现忘了unlock的情况了
class SCOPED_CAPABILITY Autolock {
public:
//其实这里不加inline也是没有关系的，在C++里编译器会自动去检查这个函数体
//如果函数体逻辑足够简单，会自动把他当成inline函数，为了养成良好的代码习惯，还是要加上
inline explicit Autolock(Mutex& mutex) ACQUIRE(mutex) : mLock(mutex) { mLock.lock(); }
inline explicit Autolock(Mutex* mutex) ACQUIRE(mutex) : mLock(*mutex) { mLock.lock(); }
inline ~Autolock() RELEASE() { mLock.unlock(); }
private:
Mutex& mLock;
// Cannot be copied or moved - declarations only
Autolock(const Autolock&);
Autolock& operator=(const Autolock&);
};
private:
friend class Condition;//友元类Condition
// A mutex cannot be copied
Mutex(const Mutex&);
Mutex& operator=(const Mutex&);
#if !defined(_WIN32)
pthread_mutex_t mMutex;
#else
void _init();
void* mState;
#endif
};
// ---------------------------------------------------------------------------
#if !defined(_WIN32)
inline Mutex::Mutex() {
pthread_mutex_init(&mMutex, nullptr);
}
inline Mutex::Mutex(__attribute__((unused)) const char* name) {
pthread_mutex_init(&mMutex, nullptr);
}
inline Mutex::Mutex(int type, __attribute__((unused)) const char* name) {
if (type == SHARED) {
pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
pthread_mutex_init(&mMutex, &attr);
pthread_mutexattr_destroy(&attr);
} else {
pthread_mutex_init(&mMutex, nullptr);
}
}
inline Mutex::~Mutex() {
pthread_mutex_destroy(&mMutex);
}
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);
}
#if defined(__ANDROID__)
inline status_t Mutex::timedLock(nsecs_t timeoutNs) {
timeoutNs += systemTime(SYSTEM_TIME_REALTIME);
const struct timespec ts = {
/* .tv_sec = */ static_cast<time_t>(timeoutNs / 1000000000),
/* .tv_nsec = */ static_cast<long>(timeoutNs % 1000000000),
};
return -pthread_mutex_timedlock(&mMutex, &ts);
}
#endif
#endif // !defined(_WIN32)
// ---------------------------------------------------------------------------
/*
* Automatic mutex. Declare one of these at the top of a function.
* When the function returns, it will go out of scope, and release the
* mutex.
*/
typedef Mutex::Autolock AutoMutex;
// ---------------------------------------------------------------------------
} // namespace android
// ---------------------------------------------------------------------------
#endif // _LIBS_UTILS_MUTEX_H
1.2 Condition代码分析
Condition条件类，在多线程同步中，主要是下面这种使用场景使用到condition。
线程A做初始化工作，而其他线程，比如线程B、C必须等到A初始化工作完后才能工作，即线程B、C在等待一个条件，我们称B、C为等待者。
当线程A完成初始化工作时，会触发这个条件，那么等待者B、C就会被唤醒。触发这个条件的A就是触发者。
上面的使用场景非常形象，而且条件类提供的函数也非常形象，它的代码如下所示：
system/core/include/utils/Condition.h
#ifndef _LIBS_UTILS_CONDITION_H
#define _LIBS_UTILS_CONDITION_H
#include <limits.h>
#include <stdint.h>
#include <sys/types.h>
#include <time.h>
#if !defined(_WIN32)
# include <pthread.h>
#endif
#include <utils/Errors.h>
#include <utils/Mutex.h>
#include <utils/Timers.h>
// ---------------------------------------------------------------------------
namespace android {
// ---------------------------------------------------------------------------
// DO NOT USE: please use std::condition_variable instead.
/*
* Condition variable class. The implementation is system-dependent.
*
* Condition variables are paired up with mutexes. Lock the mutex,
* call wait(), then either re-wait() if things aren't quite what you want,
* or unlock the mutex and continue. All threads calling wait() must
* use the same mutex for a given Condition.
*
* On Android and Apple platforms, these are implemented as a simple wrapper
* around pthread condition variables. Care must be taken to abide by
* the pthreads semantics, in particular, a boolean predicate must
* be re-evaluated after a wake-up, as spurious wake-ups may happen.
*/
class Condition {
public:
//两种类型：PRIVATE是进程内部使用的；SHARED是适用于跨进程共享的。
//如不指定，缺省是PRIVATE的类型。
enum {
PRIVATE = 0,
SHARED = 1
};
enum WakeUpType {
WAKE_UP_ONE = 0,
WAKE_UP_ALL = 1
};
Condition();// 构造函数
explicit Condition(int type);//构造函数,type就是上面的那两种类型
~Condition();//析构函数
// Wait on the condition variable. Lock the mutex before calling.
// Note that spurious wake-ups may happen.
//线程B和C等待事件，wait这个名字也很形象
status_t wait(Mutex& mutex);
// same with relative timeout
//线程B和C的超时等待，B和C可以指定等待时间，当超过这个时间，条件却还不满足，则退出等待。
status_t waitRelative(Mutex& mutex, nsecs_t reltime);
// Signal the condition variable, allowing one thread to continue.
//触发者A用来通知条件已经满足，但是B和C只有一个会被唤醒
void signal();
// Signal the condition variable, allowing one or all threads to continue.
void signal(WakeUpType type) {
if (type == WAKE_UP_ONE) {
signal();
} else {
broadcast();
}
}
// Signal the condition variable, allowing all threads to continue.
//触发者A用来通知条件已经满足，所有等待者都会被唤醒。
void broadcast();
private:
#if !defined(_WIN32)
pthread_cond_t mCond;
#else
void* mState;
#endif
};
// ---------------------------------------------------------------------------
#if !defined(_WIN32)
inline Condition::Condition() : Condition(PRIVATE) {
}
inline Condition::Condition(int type) {
pthread_condattr_t attr;
pthread_condattr_init(&attr);
#if defined(__linux__)
pthread_condattr_setclock(&attr, CLOCK_MONOTONIC);
#endif
if (type == SHARED) {
pthread_condattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
}
pthread_cond_init(&mCond, &attr);
pthread_condattr_destroy(&attr);
}
inline Condition::~Condition() {
pthread_cond_destroy(&mCond);
}
inline status_t Condition::wait(Mutex& mutex) {
return -pthread_cond_wait(&mCond, &mutex.mMutex);
}
inline status_t Condition::waitRelative(Mutex& mutex, nsecs_t reltime) {
struct timespec ts;
#if defined(__linux__)
clock_gettime(CLOCK_MONOTONIC, &ts);
#else // __APPLE__
// Apple doesn't support POSIX clocks.
struct timeval t;
gettimeofday(&t, nullptr);
ts.tv_sec = t.tv_sec;
ts.tv_nsec = t.tv_usec*1000;
#endif
// On 32-bit devices, tv_sec is 32-bit, but `reltime` is 64-bit.
int64_t reltime_sec = reltime/1000000000;
ts.tv_nsec += static_cast<long>(reltime%1000000000);
if (reltime_sec < INT64_MAX && ts.tv_nsec >= 1000000000) {
ts.tv_nsec -= 1000000000;
++reltime_sec;
}
int64_t time_sec = ts.tv_sec;
if (time_sec > INT64_MAX - reltime_sec) {
time_sec = INT64_MAX;
} else {
time_sec += reltime_sec;
}
ts.tv_sec = (time_sec > LONG_MAX) ? LONG_MAX : static_cast<long>(time_sec);
return -pthread_cond_timedwait(&mCond, &mutex.mMutex, &ts);
}
//inline函数
//signal()和broadcast()的实现是凭借调用了Raw API的pthread_cond_signal(&mCond)与pthread_cond_broadcast(&mCond)
//这里要重点说明的是，Condition类必须配合Mutex来使用。
// 在上面的代码中，不论是wait、waitRelative、signal还是broadcast的调用，都放在一个Mutex的lock和unlock范围中，尤其是wait和waitRelative函数的调用，这是强制性的。
inline void Condition::signal() {
pthread_cond_signal(&mCond);
}
inline void Condition::broadcast() {
pthread_cond_broadcast(&mCond);
}
#endif // !defined(_WIN32)
// ---------------------------------------------------------------------------
} // namespace android
// ---------------------------------------------------------------------------
#endif // _LIBS_UTILS_CONDITON_H
二、为什么android要封装AutoMutex
在android系统中，死锁是非常严重的，基本都是会引起系统死机，crash，重启的，并且死锁在android系统开发中，也是会经常碰见的。所以我们要尽量避免死锁，android就给我们封装了AutoMutex。它充分利用了c++的构造与析构机制，在构造函数中mLock.lock()加锁，在析构函数中mLock.unlock()解锁。
对一个需要加锁的函数来说，我们只需要在函数开始处，AutoMutex _l(mLock)就完成了加锁，等函数退出时，这样一个临时变量就会析构，就会解锁。
三、Autolock/AutoMutex与Condition的使用
3.1 Autolock/AutoMutex的使用
用法比较简单，定义一个局部临时的AutoMutex变量，在该变量定义的地方，构造函数被自动调用，会执行Mutex的lock()操作；在该变量作用域结束的地方，析构函数会被自动调用，会执行Mutex的unlock操作。
所以，你只需要在Mutex保护的区域开始的地方定义一个AutoMutex变量即可，即可实现用Mutex对该区域的保护。
3.2 Condition的使用
我们看一个android原生的类是怎么使用condition和Mutex的。
这个例子是Thread类的requestExitAndWait，目的是等待工作线程退出，代码如下所示：
system/core/libutils/Threads.cpp
status_t Thread::requestExitAndWait()
{
Mutex::Autolock _l(mLock);
if (mThread == getThreadId()) {
ALOGW(
"Thread (this=%p): don't call waitForExit() from this "
"Thread object's thread. It's a guaranteed deadlock!",
this);
return WOULD_BLOCK;
}
mExitPending = true;
while (mRunning == true) {
mThreadExitedCondition.wait(mLock);//这里wait
}
// This next line is probably not needed any more, but is being left for
// historical reference. Note that each interested party will clear flag.
mExitPending = false;
return mStatus;
}
那么，什么时候会触发这个条件呢？是在工作线程退出前。其代码如下所示：
int Thread::_threadLoop(void* user)
{
Thread* const self = static_cast<Thread*>(user);
sp<Thread> strong(self->mHoldSelf);
wp<Thread> weak(strong);
self->mHoldSelf.clear();
#if defined(__ANDROID__)
// this is very useful for debugging with gdb
self->mTid = gettid();
#endif
bool first = true;
do {
bool result;
if (first) {
first = false;
self->mStatus = self->readyToRun();
result = (self->mStatus == OK);
if (result && !self->exitPending()) {
// Binder threads (and maybe others) rely on threadLoop
// running at least once after a successful ::readyToRun()
// (unless, of course, the thread has already been asked to exit
// at that point).
// This is because threads are essentially used like this:
// (new ThreadSubclass())->run();
// The caller therefore does not retain a strong reference to
// the thread and the thread would simply disappear after the
// successful ::readyToRun() call instead of entering the
// threadLoop at least once.
result = self->threadLoop();
}
} else {
result = self->threadLoop();
}
// establish a scope for mLock
{
Mutex::Autolock _l(self->mLock);
if (result == false || self->mExitPending) {
self->mExitPending = true;
self->mRunning = false;
// clear thread ID so that requestExitAndWait() does not exit if
// called by a new thread using the same thread ID as this one.
self->mThread = thread_id_t(-1);
// note that interested observers blocked in requestExitAndWait are
// awoken by broadcast, but blocked on mLock until break exits scope
self->mThreadExitedCondition.broadcast(); //这里broadcast
break;
}
}
// Release our strong reference, to let a chance to the thread
// to die a peaceful death.
strong.clear();
// And immediately, re-acquire a strong reference for the next loop
strong = weak.promote();
} while(strong != nullptr);
return 0;
}
通过以上的学习，我们对Autolock/AutoMutex与Condition就有个深入的理解，
在以后android系统看到它们就知道他们的作用，已经怎么样去使用它了，达到写的代码更少的bug。
网友评论