從Cts測試testCheckForDuplicateOutput到linux kernel中Thread消耗PID

最近折騰CTS

android.security.cts

testCheckForDuplicateOutput項，單項測試很容易過，但是聯測就掛了。

源碼：http://xdecay.com/docs/android-sdk/cts/tests/tests/security/d0/db5/_cloned_secure_random_test_8java_source.php

測試的原理是：不停的創建和關閉進程，測試Pass的條件是出現兩個Pid相同的進程。。
循環進程以下：
a). 創建進程A, 記錄下A的Pid為pid⑴; 然后立即Kill pid⑴；
b). 創建進程B, 記錄下B的Pid為pid⑵; 然后立即Kill pid⑵；
……
直到再次出現記錄過的進程號。

由于Linux的PId數是有限的，
根據鴿巢原理(n個盒子裝n+1個球，必定出現1個盒子有兩個球的現象），假定PID的上線時pid_max, 那末如果創建pid_max+1個進程（其實不同時存在），那末必定會再次出現之前出現過的進程號。

 CTS 測試為了加快測試速率，調用了以下的函數（wastePids)：
比如 第1次是pid⑴, 屢次循環以后還未出現同PID的進程號，比如這時候出現了pid⑸000，那末就調用wastePids(1,5000)

按注釋翻譯而言，應當是通過創建Thread ，將可分配的剩下的Pid占用掉，讓Pid盡快循環復用。

問題來了：從傳統的thread學習而言,thread怎樣會占用Pid，Linux書籍都會告知我們，所有同1個進程下的thread同享1個Pid；更何況，JVM的線程跟Pthread的線程還不是1個東西，因此迷惑了。

查了linux內核的書籍，基本不怎樣講述thread, 這主要是pthread是1個庫，而不是Linux內核本身的1部份。

然后開始翻墻google。

找到3篇文章：

第1篇：http://www.cnblogs.com/princessd8251/articles/3914434.html
這篇文章，測試JVM能開辟的最大線程數:  發現線程數量在到達32279以后，不再增長。查了1下，32位Linux系統可創建的最大pid數是32678，這個數值可以通過/proc/sys/kernel/pid_max來做修改（修改方法同threads-max），但是在32系統下這個值只能改小，沒法更大。
雖然實際線程數，可以通過修改內核來創建更多線程，但這表明，線程數跟Pid_max是有關的；

第2篇：http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/

這篇文章分析Linux 線程實現機制
雖然，在線程庫里面，pthread的創建，使用的是多個線程share 同1個PID，但是，內核確有自己的機制:
Linux內核其實不支持真正意義上的線程，LinuxThreads是用與普通進程具有一樣內核調度視圖的輕量級進程來實現線程支持的。這些輕量級進程具有獨立的進程id，在進程調度、信號處理、IO等方面享有與普通進程1樣的能力。

這句話就表明了，內核中，采取的是輕量級的進程來支持線程的調度的，那末必定會占用Pid:

第3篇：http://blog.chinaunix.net/uid⑵7767798-id⑶470592.html

講述了Pid的分配進程：alloc_pidmap：

到這里基本就明朗了。

至于Thread如何通過VM進入到內核 參看：http://www.eoeandroid.com/blog⑵1517⑶026.html

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈