Android中同步类Mutex(AutoMutex)与Condition
在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。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· 没有源码,如何修改代码逻辑?
· NetPad:一个.NET开源、跨平台的C#编辑器
· PowerShell开发游戏 · 打蜜蜂
· 凌晨三点救火实录:Java内存泄漏的七个神坑,你至少踩过三个!