thread in android ndk

android 高版本加入了c++2.0,和2.0+的标准库的一些东西，例如：std::thread,当然低版本使用还是Thread，不过他们都封装了pthread。

我在9.0的Thread源码中发现了如下一段话：

39// DO NOT USE: please use std::thread
40
41class Thread : virtual public RefBase
42{。。。。。。

可能是引入了c++2.0 or above的标准库的缘由，也可能是Thread.cpp/Mutex.cpp等的功能不如std::来的齐全，所以不推荐使用Thread类，推荐使用std::thread类，说法不正确的话，看到的朋友可以在评论区指出下。

std::相关

android使用的实现库是llvm的libc++库,thread是一个class，看一下构造函数：

//std::thread  in thread [no suffix] file
290	thread::thread(_Fp&& __f, _Args&&... __args)
291	{
292	    typedef unique_ptr<__thread_struct> _TSPtr;
293	    _TSPtr __tsp(new __thread_struct);
294	    typedef tuple<_TSPtr, typename decay<_Fp>::type, typename decay<_Args>::type...> _Gp;
295	    _VSTD::unique_ptr<_Gp> __p(
296	            new _Gp(std::move(__tsp),
297	                    __decay_copy(_VSTD::forward<_Fp>(__f)),
298	                    __decay_copy(_VSTD::forward<_Args>(__args))...));
299	    int __ec = __libcpp_thread_create(&__t_, &__thread_proxy<_Gp>, __p.get());
300	    if (__ec == 0)
301	        __p.release();
302	    else
303	        __throw_system_error(__ec, "thread constructor failed");
304	}


276	template <class _Fp>
277	void* __thread_proxy(void* __vp)
278	{
279	    // _Fp = std::tuple< unique_ptr<__thread_struct>, Functor, Args...>
280	    std::unique_ptr<_Fp> __p(static_cast<_Fp*>(__vp));
281	    __thread_local_data().set_pointer(_VSTD::get<0>(*__p).release());
282	    typedef typename __make_tuple_indices<tuple_size<_Fp>::value, 2>::type _Index;
283	    __thread_execute(*__p, _Index());
284	    return nullptr;
285	}

//__threading_support[no suffix]
333	int __libcpp_thread_create(__libcpp_thread_t *__t, void *(*__func)(void *),
334	                           void *__arg)
335	{
336	  return pthread_create(__t, 0, __func, __arg);
337	}

最终调用到了pthread的pthread_create方法。

//std::mutex [mutex.cpp]
30	void
31	mutex::lock()
32	{
33	    int ec = __libcpp_mutex_lock(&__m_);//!!!
34	    if (ec)
35	        __throw_system_error(ec, "mutex lock failed");
36	}

44	void
45	mutex::unlock() _NOEXCEPT
46	{
47	    int ec = __libcpp_mutex_unlock(&__m_);//!!!
48	    (void)ec;
49	    _LIBCPP_ASSERT(ec == 0, "call to mutex::unlock failed");
50	}

//mutex_destructor.cpp
31	class _LIBCPP_TYPE_VIS mutex
32	{
33	    __libcpp_mutex_t __m_ = _LIBCPP_MUTEX_INITIALIZER;//!!!
34	
35	public:
36	    _LIBCPP_ALWAYS_INLINE _LIBCPP_INLINE_VISIBILITY
37	    constexpr mutex() = default;
38	    mutex(const mutex&) = delete;
39	    mutex& operator=(const mutex&) = delete;
40	    ~mutex() noexcept;
41	};
42	
43	
44	mutex::~mutex() _NOEXCEPT
45	{
46	    __libcpp_mutex_destroy(&__m_);//!!!
47	}

//__threading_support [no suffix]
57	typedef pthread_mutex_t __libcpp_mutex_t;//!!!

262	int __libcpp_mutex_lock(__libcpp_mutex_t *__m)
263	{
264	  return pthread_mutex_lock(__m);//!!!
265	}

272	int __libcpp_mutex_unlock(__libcpp_mutex_t *__m)
273	{
274	  return pthread_mutex_unlock(__m);//!!!
275	}

277	int __libcpp_mutex_destroy(__libcpp_mutex_t *__m)
278	{
279	  return pthread_mutex_destroy(__m);//!!!
280	}

///bionic/libc/include/pthread.h
41enum {
42  PTHREAD_MUTEX_NORMAL = 0,
43  PTHREAD_MUTEX_RECURSIVE = 1,
44  PTHREAD_MUTEX_ERRORCHECK = 2,
45
46  PTHREAD_MUTEX_ERRORCHECK_NP = PTHREAD_MUTEX_ERRORCHECK,
47  PTHREAD_MUTEX_RECURSIVE_NP  = PTHREAD_MUTEX_RECURSIVE,
48
49  PTHREAD_MUTEX_DEFAULT = PTHREAD_MUTEX_NORMAL
50};

52#define PTHREAD_MUTEX_INITIALIZER { { ((PTHREAD_MUTEX_NORMAL & 3) << 14) } }

std::mutex的lock()，unlock()，~mutex()也是通过_libcpp中转到了pthread_mutex_lock，pthread_mutex_unlock，pthread_mutex_destroy，让pthread承担起来。

其他的互斥体也是如此，不一一罗列。

 Thread相关

 /system/core/libutils/Threads.cpp

使用Thread，sp<Thread> t = new Thread(false); t.run("threadname",PRIORITY_NORMAL);最终会调用到pthread的pthread_create方法。

/system/core/libutils/include/utils/Mutex.h

162inline Mutex::Mutex() {
163    pthread_mutex_init(&mMutex, NULL);
164}
165inline Mutex::Mutex(__attribute__((unused)) const char* name) {
166    pthread_mutex_init(&mMutex, NULL);
167}
168inline Mutex::Mutex(int type, __attribute__((unused)) const char* name) {
169    if (type == SHARED) {
170        pthread_mutexattr_t attr;
171        pthread_mutexattr_init(&attr);
172        pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
173        pthread_mutex_init(&mMutex, &attr);
174        pthread_mutexattr_destroy(&attr);
175    } else {
176        pthread_mutex_init(&mMutex, NULL);
177    }
178}
179inline Mutex::~Mutex() {
180    pthread_mutex_destroy(&mMutex);
181}
182inline status_t Mutex::lock() {
183    return -pthread_mutex_lock(&mMutex);
184}
185inline void Mutex::unlock() {
186    pthread_mutex_unlock(&mMutex);
187}
188inline status_t Mutex::tryLock() {
189    return -pthread_mutex_trylock(&mMutex);
190}
191#if defined(__ANDROID__)
192inline status_t Mutex::timedLock(nsecs_t timeoutNs) {
193    timeoutNs += systemTime(SYSTEM_TIME_REALTIME);
194    const struct timespec ts = {
195        /* .tv_sec = */ static_cast<time_t>(timeoutNs / 1000000000),
196        /* .tv_nsec = */ static_cast<long>(timeoutNs % 1000000000),
197    };
198    return -pthread_mutex_timedlock(&mMutex, &ts);
199}
200#endif

Mutex也是使用到了pthread。

std::和Thread这两项，都用到了pthread，可见pthread在android中的重要性。java中LockSupport的native使用的也是pthread.

其实pthread是我的叫法，它的正确叫法是Pthreads，POSIX Threads，是POSIX的线程标准，定义了创建和操纵线程的一套API。

标准就是指API，它是跨平台(os)的接口，android可能借用linux的Pthreads库，实现了这套标准。看来制定标准的都在想着要做老大。

pthread lock and unlock

锁类型有三种：1.MUTEX_TYPE_BITS_NORMAL普通锁，非其余两种，2.MUTEX_TYPE_BITS_RECURSIVE支持重入，3. MUTEX_TYPE_BITS_ERRORCHECK，支持错误检查。我们只看普通锁。

798int pthread_mutex_lock(pthread_mutex_t* mutex_interface) {
......
807
808    pthread_mutex_internal_t* mutex = __get_internal_mutex(mutex_interface);
//原子load到state的字段值
809    uint16_t old_state = atomic_load_explicit(&mutex->state, memory_order_relaxed);
810    uint16_t mtype = (old_state & MUTEX_TYPE_MASK);
       //避免减慢获取正常互斥锁的快速路径，TryLock一次
811    // Avoid slowing down fast path of normal mutex lock operation.
812    if (__predict_true(mtype == MUTEX_TYPE_BITS_NORMAL)) {
813        uint16_t shared = (old_state & MUTEX_SHARED_MASK);
//
814        if (__predict_true(NonPI::NormalMutexTryLock(mutex, shared) == 0)) {
815            return 0;
816        }
817    }
......
        //没有获取到，state的1-0位非0
829    return NonPI::MutexLockWithTimeout(mutex, false, nullptr);
830}

其中pthread_mutex_internal_t有2种机器下的定义：一种是指针位是64位，还有一种是32位的，我只看32位的：

471struct pthread_mutex_internal_t {
472    _Atomic(uint16_t) state;
473    union {
474        _Atomic(uint16_t) owner_tid;
475        uint16_t pi_mutex_id;
476    };
477
478    PIMutex& ToPIMutex() {
479        return PIMutexAllocator::IdToPIMutex(pi_mutex_id);
480    }
481
482    void FreePIMutex() {
483        PIMutexAllocator::FreeId(pi_mutex_id);
484    }
485} __attribute__((aligned(4)));

可以看到pthread_mutex_internal_t 类型的变量在内存中的排放是： _Atomic(uint16_t) state + union.

//对于32位互斥锁，它包括以下字段：
435//   Atomic(uint16_t) state;
436//   atomic_int owner_tid;  // 32位程序中的Atomic（uint16_t）
437//
438//   state包含以下字段：
439//
440//   bits:     name     description
441//   15-14     type     mutex type, can be 0 (normal), 1 (recursive), 2 (errorcheck)
442//   13        shared   process-shared flag
443//   12-2      counter  <number of times a thread holding a recursive Non-PI mutex> - 1
444//   1-0       state    lock state (0, 1 or 2)
445//
446//   bits 15-13 are constant during the lifetime of the mutex.
   //   15-13位在互斥对象的生存期内是不变的。
447//
448//   owner_tid is used only in recursive and errorcheck Non-PI mutexes to hold the mutex owner thread id.
//owner_tid仅用于递归和错误检查以保持互斥锁所有者

16位原子变量state的1-0位的值，0表示未锁定，1表示有一个线程取走了锁，2表示有1+个线程在等待获取锁。接下来在lock和unlock的时候，我们关注16位原子变量state的1-0两位的变换，以及致使其变化的一些原子操作。

先看trylock:

554static inline __always_inline int NormalMutexTryLock(pthread_mutex_internal_t* mutex,
555                                                     uint16_t shared) {
//16位unlocked的1-0为0
556    const uint16_t unlocked           = shared | MUTEX_STATE_BITS_UNLOCKED;
//16位locked_uncontended的1-0为1
557    const uint16_t locked_uncontended = shared | MUTEX_STATE_BITS_LOCKED_UNCONTENDED;
558
559    uint16_t old_state = unlocked;
//比较&mutex->state和&old_state并交换locked_uncontended到&mutex->state，成功的话state字段1-0为1，示为有一个线程获取了锁。
560    if (__predict_true(atomic_compare_exchange_strong_explicit(&mutex->state, &old_state,
561                         locked_uncontended, memory_order_acquire, memory_order_relaxed))) {
562        return 0;
563    }
564    return EBUSY;
565}

假定trylock失败了，可能的失败是：已经有1个线程获取了锁(1-0位为1)，或者1+个线程在等待(1-0位为1).失败就走至NonPI::MutexLockWithTimeout(mutex, false, nullptr)。

701static int MutexLockWithTimeout(pthread_mutex_internal_t* mutex, bool use_realtime_clock,
702                                const timespec* abs_timeout_or_null) {
703    uint16_t old_state = atomic_load_explicit(&mutex->state, memory_order_relaxed);
704    uint16_t mtype = (old_state & MUTEX_TYPE_MASK);
705    uint16_t shared = (old_state & MUTEX_SHARED_MASK);
706
707    // Handle common case first.
708    if ( __predict_true(mtype == MUTEX_TYPE_BITS_NORMAL) ) {
709        return NormalMutexLock(mutex, shared, use_realtime_clock, abs_timeout_or_null);
710    }
......
782}


579static inline __always_inline int NormalMutexLock(pthread_mutex_internal_t* mutex,
580                                                  uint16_t shared,
581                                                  bool use_realtime_clock,
582                                                  const timespec* abs_timeout_or_null) {
583    if (__predict_true(NormalMutexTryLock(mutex, shared) == 0)) {
584        return 0;
585    }
586    int result = check_timespec(abs_timeout_or_null, true);
587    if (result != 0) {
588        return result;
589    }
590
591    ScopedTrace trace("Contending for pthread mutex");
//16位unlocked的1-0为0
593    const uint16_t unlocked           = shared | MUTEX_STATE_BITS_UNLOCKED;
//16位locked_contended 的1-0为2
594    const uint16_t locked_contended = shared | MUTEX_STATE_BITS_LOCKED_CONTENDED;
......
//原子交换&mutex->state和locked_contended的值，如果&mutex->state旧值的1-0位不是0(未锁定)，说明有至少一个线程获取了锁。
604    while (atomic_exchange_explicit(&mutex->state, locked_contended,
605                                    memory_order_acquire) != unlocked) {
//只允许一个线程获取锁，其他线程在此被内核加入了进程等待队列，等待被唤醒。
606        if (__futex_wait_ex(&mutex->state, shared, locked_contended, use_realtime_clock,
607                            abs_timeout_or_null) == -ETIMEDOUT) {
608            return ETIMEDOUT;
609        }
610    }
611    return 0;
612}

看一下unlock：

832int pthread_mutex_unlock(pthread_mutex_t* mutex_interface) {
。。。。。。
841
842    pthread_mutex_internal_t* mutex = __get_internal_mutex(mutex_interface);
843    uint16_t old_state = atomic_load_explicit(&mutex->state, memory_order_relaxed);
844    uint16_t mtype  = (old_state & MUTEX_TYPE_MASK);
845    uint16_t shared = (old_state & MUTEX_SHARED_MASK);
846
847    // Handle common case first.
848    if (__predict_true(mtype == MUTEX_TYPE_BITS_NORMAL)) {
849        NonPI::NormalMutexUnlock(mutex, shared);
850        return 0;
851    }
。。。。。。
887    return 0;
888}


618static inline __always_inline void NormalMutexUnlock(pthread_mutex_internal_t* mutex,
619                                                     uint16_t shared) {
620    const uint16_t unlocked         = shared | MUTEX_STATE_BITS_UNLOCKED;
621    const uint16_t locked_contended = shared | MUTEX_STATE_BITS_LOCKED_CONTENDED;
。。。。。。
//原子交换&mutex->state和unlocked的值，如果&mutex->state旧值的1-0位是2(未锁定)，说明有至少一个线程在等待获取锁。
628    if (atomic_exchange_explicit(&mutex->state, unlocked,
629                                 memory_order_release) == locked_contended) {
。。。。。。
//好，既然有等待的线程，那么我们就唤醒在&mutex->state等待的线程，可能是非公平锁，唤醒所有线程去竞争。
648        __futex_wake_ex(&mutex->state, shared, 1);
649    }
650}

总结一下lock和unlock：

//lock
void lock(pthread_mutex_internal_t* mutex) {
//trylock is successed
    uint16_t old_state = atomic_load_explicit(&mutex->state, memory_order_relaxed)
    const uint16_t unlocked         = old_state | MUTEX_STATE_BITS_UNLOCKED;
    old_state = unlocked;
    if (__predict_true(atomic_compare_exchange_strong_explicit(&mutex->state, &old_state, locked_uncontended, memory_order_acquire, memory_order_relaxed))) {
        return 0;
    }
//trylock is failed
    uint16_t old_state = atomic_load_explicit(&mutex->state, memory_order_relaxed)
    const uint16_t unlocked         = old_state | MUTEX_STATE_BITS_UNLOCKED;
    const uint16_t locked_contended = old_state | MUTEX_STATE_BITS_LOCKED_CONTENDED;
//唤醒后的线程继续在此原子修改&mutex->state为locked_contended，先修改的线程不用再等待(unlock时修改为unlocked了)先进入临界区，后修改的返回值一直为locked_contended(!=unlocked)，所以继续等待
    while (atomic_exchange_explicit(&mutex->state, locked_contended, memory_order_acquire) != unlocked) {
        if (__futex_wait_ex(&mutex->state, shared, locked_contended, use_realtime_clock, abs_timeout_or_null) == -ETIMEDOUT) {
            return ETIMEDOUT;
        }
    }
}

//unlock
void unlock(pthread_mutex_internal_t* mutex) {
       uint16_t old_state = atomic_load_explicit(&mutex->state, memory_order_relaxed)
       const uint16_t unlocked         = old_state | MUTEX_STATE_BITS_UNLOCKED;
       const uint16_t locked_contended = old_state | MUTEX_STATE_BITS_LOCKED_CONTENDED;
//把&mutex->state重新置换为未锁定状态，有线程等待的话就唤醒在&mutex->state上等待的线程，唤醒后干甚就取看看lock里干了什么
       if (atomic_exchange_explicit(&mutex->state, unlocked,memory_order_release) == locked_contended) {
           __futex_wake_ex(&mutex->state, shared, 1);
       }
}

但是我觉着把上面的atomic_compare_exchange_strong_explicit和atomic_exchange_explicit的memory_order换成memory_order_relaxed也是没有问题的。不知道此推断对不对，看到的可以讨论下。