Thread consumption PID from CTS test Testcheckforduplicateoutput to Linux kernel

Recent Toss CTS

Android.security.cts

Testcheckforduplicateoutput, the individual tests are easy to get through, but the joint test is hung up.

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

the principle of testing is: the process of creating and closing continuously, test pass is the premise of two PID same process. .
The loop process is as follows:
a). Create process A, record A's PID as pid-1; Then kill Pid-1 immediately;
b). Create process B, record the PID of B as pid-2; Then kill Pid-2 immediately;
...
until the logged process number appears again.

because the PID number of Linux is limited,
according to the Pigeon Nest principle (n boxes to n+1 a ball, there must be a box with two ball phenomenon), assuming that the PID Pid_max, if the creation of Pid_max process (does not exist at the same time), thenthe process numbers that have occurred before will inevitably reappear.

 cts  test to speed up the test rate, called the following function (wastepids):
For example   The first time is pid-1,  after multiple cycles have not appeared with the PID process number, such as the occurrence of pid-5000, then call Wastepids ( 1,5000)

    /** * This is a attempt to get the PIDs to roll over     faster.  Threads use up     * PIDs on Android and spawning a new thread was much faster than having     * Another service spawned as We is doing in the this test.     */    private static void Wastepids (int firstpid, int previouspid) {        int distance = (Firstpid-previouspid + max_pid )% Max_pid;         Don ' t waste PIDs if we ' re close to Wrap-around to improve odds of        //collision.        if ((Distance < pid_wasting_skip_lower) | | (Max_pid-distance < Pid_wasting_skip_upper)) {            return;        }         for (int i = 0; i < distance; i++) {            thread t = new Thread ();            T.start ();        }    }

In terms of annotation translation, it should be done by creating a thread that will take out the rest of the assigned PID and allow the PID to be reused as soon as possible.

The question is: from the traditional thread learning, how does thread consume PID, Linux Books will tell us that all threads in the same process share a PID, not to mention that the thread of the JVM and the thread of pthread are not yet a thing, and therefore confusing.

Check the Linux kernel books, basically do not tell the thread, this is mainly pthread is a library, rather than the Linux kernel itself part.

Then start flipping the wall to Google.

3 article found:

First article: http://www.cnblogs.com/princessd8251/articles/3914434.html
in this article, test the maximum number of threads the JVM can open up: The number of threads found to be 32279, no longer growing. Checked, the 32-bit Linux system can be created by the maximum number of PID is 32678, this value can be modified by/proc/sys/kernel/pid_max (modified method and Threads-max), but in the 32 system this value can only be changed to small, not larger.
Although the actual number of threads, you can modify the kernel to create more threads, but this indicates that the number of threads is related to Pid_max;

Article two: http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/

This article analyzes the Linux threading implementation mechanism
Although the online libraries inside, Pthread is created using multiple threads share the same PID, however, the kernel does have its own mechanism:
The Linux kernel does not support a true thread, and Linuxthreads is supported by a lightweight process that has the same kernel scheduling view as a normal process. These lightweight processes have independent process IDs that enjoy the same capabilities as normal processes in process scheduling, signal processing, and IO.

This statement shows that, in the kernel, using a lightweight process to support the scheduling of threads, it will inevitably occupy the PID:

Article three: http://blog.chinaunix.net/uid-27767798-id-3470592.html

describes the PID allocation process: Alloc_pidmap:

  static int Alloc_pidmap (struct pid_namespace *pid_ns) {         int i, offset, Max_scan, pid, last = pid_ns->last_pid;  Remove last_pid         struct pidmap *map;           PID = last + 1;                                      Here last+1, get the alternative pid//if the PID to Pidmax, then start looking for the available PID, starting from Reserved_pids, keep the PID number before reserved_pids, the default if         (PID >= Pid_max)                 pid = reserved_pids;         ......}

Indicate that the PID is from low to high allocation, when more than Pid_max, then start looking for available PID, starting from Reserved_pids, retain the PID number before reserved_pids, default 300

It's almost clear to be here.

As for how the thread goes through the VM into the kernel see: http://www.eoeandroid.com/blog-21517-3026.html

Thread consumption PID from CTS test Testcheckforduplicateoutput to Linux kernel