Android Framework学习(七)之Thread类以及常用同步类

Thread类是Android为线程操作而做的一个封装。代码在Thread.cpp中,其中还封装了一些与线程同步相关的类,,本篇博客,我们一起学习Thread类以及常用同步类。

Thread类

Thread类的构造函数中的有一个canCallJava
Thread.cpp

status_t Thread::run(const char* name, int32_tpriority, size_t stack)
{
   Mutex::Autolock_l(mLock);
    ....
   //如果mCanCallJava为真,则调用createThreadEtc函数,线程函数是_threadLoop。
 //_threadLoop是Thread.cpp中定义的一个函数。
   if(mCanCallJava) {
       res = createThreadEtc(_threadLoop,this, name, priority,
                                   stack,&mThread);
    } else{
       res = androidCreateRawThreadEtc(_threadLoop, this, name, priority,
                                   stack,&mThread);
    }

上面的mCanCallJava将线程创建函数的逻辑分为两个分支,虽传入的参数都有_threadLoop,但调用的函数却不同。先直接看mCanCallJava为true的这个分支
Thread.h::createThreadEtc()

inline bool createThreadEtc(thread_func_tentryFunction,
                            void *userData,
                            const char*threadName = "android:unnamed_thread",
                            int32_tthreadPriority = PRIORITY_DEFAULT,
                            size_tthreadStackSize = 0,
                            thread_id_t*threadId = 0)
{
    return androidCreateThreadEtc(entryFunction, userData, threadName,
                   threadPriority, threadStackSize,threadId) ? true : false;
}

它调用的是androidCreateThreadEtc函数

// gCreateThreadFn是函数指针,初始化时和mCanCallJava为false时使用的是同一个
//线程创建函数。
static android_create_thread_fn gCreateThreadFn= androidCreateRawThreadEtc;
int androidCreateThreadEtc(android_thread_func_tentryFunction,
                            void*userData,const char* threadName,
                            int32_tthreadPriority,size_t threadStackSize,
                            android_thread_id_t*threadId)
{
    return gCreateThreadFn(entryFunction, userData, threadName,
                               threadPriority,threadStackSize, threadId);
}

androidCreateThreadEtc方法最终会调用CreateThreadFn方法,初始化时和mCanCallJava为false时使用的是同一个
线程创建函数,所以我们要看一下到底什么地方会修改这个mCanCallJava的值。答案就在AndroidRuntime调用startReg的地方,就有可能修改这个函数指针
AndroidRuntime.cpp

/*static*/ int AndroidRuntime::startReg(JNIEnv*env)
{
   //这里会修改函数指针为javaCreateThreadEtc
  androidSetCreateThreadFunc((android_create_thread_fn)javaCreateThreadEtc);
  return 0;
}

所以,如果mCanCallJava为true,则将调用javaCreateThreadEtc。
AndroidRuntime.cpp

nt AndroidRuntime::javaCreateThreadEtc(
                               android_thread_func_tentryFunction,
                                void* userData,
                                const char*threadName,
                                int32_tthreadPriority,
                                size_t threadStackSize,
                               android_thread_id_t* threadId)
{
    void**args = (void**) malloc(3 * sizeof(void*));  
    intresult;
   args[0] = (void*) entryFunction;
   args[1] = userData;
   args[2] = (void*) strdup(threadName);
    //调用的还是androidCreateRawThreadEtc,但线程函数却换成了javaThreadShell。
    result= androidCreateRawThreadEtc(AndroidRuntime::javaThreadShell, args,
                         threadName, threadPriority,threadStackSize, threadId);
    return result;
}

AndroidRuntime.cpp

int AndroidRuntime::javaThreadShell(void* args){
      ......
     intresult;
    //把这个线程attach到JNI环境中,这样这个线程就可以调用JNI的函数了
    if(javaAttachThread(name, &env) != JNI_OK)
       return -1;
     //调用实际的线程函数干活
     result = (*(android_thread_func_t)start)(userData);
   //从JNI环境中detach出来。
   javaDetachThread();
   free(name);
    returnresult;
}

到这里,终于明白了mCanCallJava为true的目的:
1.在调用你的线程函数之前会attach到 JNI环境中,这样,你的线程函数就可以无忧无虑地使用JNI函数了。
2.线程函数退出后,它会从JNI环境中detach,释放一些资源。
进程退出前,dalvik虚拟机会检查是否有attach了,但是最后未detach的线程如果有,则会直接abort,这显然是不好的。

_threadLoop

还记得上面的代码

  if(mCanCallJava) {
       res = createThreadEtc(_threadLoop,this, name, priority,
                                   stack,&mThread);
    } else{
       res = androidCreateRawThreadEtc(_threadLoop, this, name, priority,
                                   stack,&mThread);
    }

尽管根据mCanCallJava不同会调用不同的函数,但是都是传入了_threadLoop,所以我们有必要分析这个方法。

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 HAVE_ANDROID_OS
   self->mTid = gettid();
#endif

    boolfirst = true;

    do {
       bool result;
        if(first) {
           first = false;
          //self代表继承Thread类的对象,第一次进来将调用readyToRun,看看是否准备好
          self->mStatus = self->readyToRun();
           result = (self->mStatus == NO_ERROR);

           if (result && !self->mExitPending) {
                result = self->threadLoop();
           }
        }else {
          /* 调用子类实现的threadLoop函数,注意这段代码运行在一个do-while循环中。 这表示即使我们的threadLoop返回了,线程也不一定会退出。 */
           result = self->threadLoop();
        }
   /* 线程退出的条件: 1)result 为false。这表明,如果子类在threadLoop中返回false,线程就可以 退出。这属于主动退出的情况,是threadLoop自己不想继续干活了,所以返回false。千万别写错threadLoop的返回值。 2)mExitPending为true,这个变量可由Thread类的requestExit函数设置,这种 情况属于被动退出,因为由外界强制设置了退出条件。 */
        if(result == false || self->mExitPending) {
           self->mExitPending = true;
           self->mLock.lock();
           self->mRunning = false;
           self->mThreadExitedCondition.broadcast();
           self->mLock.unlock();
           break;
        }
       strong.clear();
       strong = weak.promote();
    }while(strong != 0);

    return 0;
}

_threadLoop运行在一个循环中,它的返回值可以决定是否退出线程。

常用同步类

互斥类——Mutex
Mutex是互斥类,用于多线程访问同一个资源的时候,保证一次只能有一个线程能访问该资源。例如想象你在飞机上如厕,这时卫生间的信息牌上显示“有人”,你必须等里边的人出来后才可进去。这就是互斥的含义。

Thread.h::Mutex的声明和实现

inline Mutex::Mutex(int type, const char* name){
    if(type == SHARED) {
      //type如果是SHARED,则表明这个Mutex支持跨进程的线程同步
      //在Audio系统和Surface系统中会经常见到这种用法
       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, NULL);
    }
}
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);
}

关于Mutex的使用,除了初始化外,最重要的是lock和unlock函数的使用,它们的用法如下:
要想独占卫生间,必须先调用Mutex的lock函数。这样,这个区域就被锁住了。如果这块区域之前已被别人锁住,lock函数则会等待,直到可以进入这块区域为止。系统保证一次只有一个线程能lock成功。
· 当你“方便”完毕,记得调用Mutex的unlock以释放互斥区域。这样,其他人的lock才可以成功返回。
· 另外,Mutex还提供了一个trylock函数,该函数只是尝试去锁住该区域,使用者需要根据trylock的返回值判断是否成功锁住了该区域。

AutoLock介绍
AutoLock类是定义在Mutex内部的一个类,Mutex的使用如下
· 显示调用Mutex的lock。
· 在某个时候要记住调用该Mutex的unlock。以上这些操作都必须一一对应,否则会出现“死锁”!充分利用了C++的构造和析构函数,可以达到不忘了释放锁的目的。
Thread.h Mutex::Autolock声明和实现

   classAutolock {
   public:
        //构造的时候调用lock
       inline Autolock(Mutex& mutex) : mLock(mutex)  { mLock.lock(); }
       inline Autolock(Mutex* mutex) : mLock(*mutex) { mLock.lock(); }
        //析构的时候调用unlock
       inline ~Autolock() { mLock.unlock(); }
   private:
       Mutex& mLock;
    };

AutoLock的用法很简单:
· 先定义一个Mutex,如 Mutex xlock;
· 在使用xlock的地方,定义一个AutoLock,如 AutoLock autoLock(xlock)。
由于C++对象的构造和析构函数都是自动被调用的,所以在AutoLock的生命周期内,xlock的lock和unlock也就自动被调用了,这样就省去了重复书写unlock的麻烦,而且lock和unlock的调用肯定是一一对应的,这样就绝对不会出错。

条件类——Condition
· 线程A做初始化工作,而其他线程比如线程B、C必须等到初始化工作完后才能工作,即线程B、C在等待一个条件,我们称B、C为等待者。
· 当线程A完成初始化工作时,会触发这个条件,那么等待者B、C就会被唤醒。触发这个条件的A就是触发者。
Thread.h::Condition的声明和实现

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

   Condition();
   Condition(int type);//如果type是SHARED,表示支持跨进程的条件同步
   ~Condition();
    //线程B和C等待事件,wait这个名字是不是很形象呢?
   status_t wait(Mutex& mutex);
  //线程B和C的超时等待,B和C可以指定等待时间,当超过这个时间,条件却还不满足,则退出等待
   status_t waitRelative(Mutex& mutex, nsecs_t reltime);
    //触发者A用来通知条件已经满足,但是B和C只有一个会被唤醒
    voidsignal();
    //触发者A用来通知条件已经满足,所有等待者都会被唤醒
    voidbroadcast();

private:
#if defined(HAVE_PTHREADS)
   pthread_cond_t mCond;
#else
   void*   mState;
#endif
}

声明很简单,定义也很简单

inline Condition::Condition() {
   pthread_cond_init(&mCond, NULL);
}
inline Condition::Condition(int type) {
    if(type == SHARED) {//设置跨进程的同步支持
       pthread_condattr_t attr;
        pthread_condattr_init(&attr);
       pthread_condattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
       pthread_cond_init(&mCond, &attr);
       pthread_condattr_destroy(&attr);
    } else{
       pthread_cond_init(&mCond, NULL);
    }
}
inline Condition::~Condition() {
   pthread_cond_destroy(&mCond);
}
inline status_t Condition::wait(Mutex&mutex) {
    return-pthread_cond_wait(&mCond, &mutex.mMutex);
}
inline status_tCondition::waitRelative(Mutex& mutex, nsecs_t reltime) {
#if defined(HAVE_PTHREAD_COND_TIMEDWAIT_RELATIVE)
    structtimespec ts;
   ts.tv_sec  = reltime/1000000000;
   ts.tv_nsec = reltime%1000000000;
    return-pthread_cond_timedwait_relative_np(&mCond, &mutex.mMutex, &ts);
    ...... //有些系统没有实现POSIX的相关函数,所以不同系统需要调用不同的函数
#endif
}
inline void Condition::signal() {
   pthread_cond_signal(&mCond);
}
inline void Condition::broadcast() {
   pthread_cond_broadcast(&mCond);
}

可以看出,Condition的实现全是凭借调用了Raw API的pthread_cond_xxx函数。这里要重点说明的是,Condition类必须配合Mutex来使用。上面代码中,不论是wait、waitRelative、signal还是broadcast的调用,都放在一个Mutex的lock和unlock范围中,尤其是wait和waitRelative函数的调用,这是强制性的。

Condition类和Mutex类使用的例子,在Thread类的requestExitAndWait中就可以体现
Thread.cpp

status_t Thread::requestExitAndWait()
{
    ......
   requestExit();//设置退出变量mExitPending为true
    Mutex::Autolock_l(mLock);//使用Autolock,mLock被锁住
    while(mRunning == true) {
    /* 条件变量的等待,这里为什么要通过while循环来反复检测mRunning? 因为某些时候即使条件类没有被触发,wait也会返回。 */
      mThreadExitedCondition.wait(mLock);
    }

   mExitPending = false;
   //退出前,局部变量Mutex::Autolock _l的析构会被调用,unlock也就会被自动调用。
    returnmStatus;
}

Thread.cpp

int Thread::_threadLoop(void* user)
{
    Thread* const self =static_cast<Thread*>(user);
   sp<Thread> strong(self->mHoldSelf);
   wp<Thread> weak(strong);
   self->mHoldSelf.clear();

    do {
          ......  
          result= self->threadLoop();//调用子类的threadLoop函数
           ......
         //如果mExitPending为true,则退出
        if(result == false || self->mExitPending) {
           self->mExitPending = true;
           //退出前触发条件变量,唤醒等待者
           self->mLock.lock();//lock锁住
           //mRunning的修改位于锁的保护中。
            self->mRunning = false;
           self->mThreadExitedCondition.broadcast();
           self->mLock.unlock();//释放锁
           break;//退出循环,此后该线程函数会退出
        }
       ......
    }while(strong != 0);

    return0;
}

原子操作函数
所谓原子操作,就是该操作绝不会在执行完毕前被任何其他任务或事件打断,也就说,原子操作是最小的执行单位

static int g_flag = 0; //全局变量g_flag
static Mutex lock  ;//全局的锁
//线程1执行thread1
void thread1()
{
  //g_flag递减,每次操作前锁住
  lock.lock();
   g_flag--;
 lock.unlock();
}
//线程2中执行thread2函数
void thread2()
{
  lock.lock();
  g_flag++; //线程2对g_flag进行递增操作,每次操作前要取得锁
lock.unlock();
}

为什么需要Mutex来帮忙呢?因为g_flags++或者g_flags—操作都不是原子操作。从汇编指令的角度看,C/C++中的一条语句对应了数条汇编指令。以g_flags++操作为例,它生成的汇编指令可能就是以下三条:
· 从内存中取数据到寄存器。
· 对寄存器中的数据进行递增操作,结果还在寄存器中。
· 寄存器的结果写回内存。
这三条汇编指令,如果按正常的顺序连续执行,是没有问题的,但在多线程时就不能保证了。例如,线程1在执行第一条指令后,线程2由于调度的原因,抢先在线程1之前连续执行完了三条指令。这样,线程1继续执行指令时,它所使用的值就不是线程2更新后的值,而是之前的旧值。再对这个值进行操作便没有意义了。
在一般情况下,处理这种问题可以使用Mutex来加锁保护,但Mutex的使用比它所要保护的内容还复杂,例如,锁的使用将导致从用户态转入内核态,有较大的浪费。那么,有没有简便些的办法让这些加、减等操作不被中断呢?
Android提供了相关的原子操作函数。这里,有必要介绍一下各个函数的作用。
Atomic.h
注意该文件位置在system/core/include/cutils目录中

//原子赋值操作,结果是*addr=value
void android_atomic_write(int32_t value,volatile int32_t* addr);
//下面所有函数的返回值都是操作前的旧值
//原子加1和原子减1
int32_t android_atomic_inc(volatile int32_t*addr);
int32_t android_atomic_dec(volatile int32_t*addr);
//原子加法操作,value为被加数
int32_t android_atomic_add(int32_t value,volatile int32_t* addr);
//原子“与”和“或”操作
int32_t android_atomic_and(int32_t value,volatile int32_t* addr);
int32_t android_atomic_or(int32_t value,volatile int32_t* addr);
/* 条件交换的原子操作。只有在oldValue等于*addr时,才会把newValue赋值给*addr 这个函数的返回值须特别注意。返回值非零,表示没有进行赋值操作。返回值为零,表示 进行了原子操作。 */
int android_atomic_cmpxchg(int32_t oldvalue,int32_t newvalue,
                                volatile int32_t*addr);

声明:本博客内容,均参考自《深入理解安卓:卷1》

    原文作者:伯努力不努力
    原文地址: https://blog.csdn.net/u012124438/article/details/71104783
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞