ULK --- Chap3 Processes: Identifying a Process
2015-11-05 06:18
387 查看
As a general rule, each execution context that can be independently scheduled must have its own
process descriptor; therefore, even lightweight processes, which share a large portion of their kernel
data structures, have their own task_struct structures.
The strict one-to-one correspondence between the process and process descriptor makes the 32 bit
address of the task_struct a useful means for the kernel to identify processes. These addresses are referred
to as process descriptor pointers. Most of the references to processes that the kernel makes are through
process descriptor pointers.
On the other hand, Unix-like operating sytems allow usres to identify processes by means of a number
called the Process ID (or PID), which is stored in the pid field of the process descriptor. PIDs are numbered
sequentially: the PID of a newly created process is normally the PID of the previously created process
increased by one. Of course, there is an upper limit on the PID values; when the kernel reaches such limit,
it must start recycling the lower, unused PIDs. By default, the maximum PID number is 32767 (
PID_MAX_DEFAULT - 1); the system administrator may reduce this limit by writing a smaller value into
the /proc/sys/kernel/pid_max file. In 64-bit architectures, the system administrator can enlarge the
maximum number up to 4194303.
When recycling PID numbers, the kernel must manage a pidmap_array bitmap that denotes which are the
PIDs currently assigned and which are the free ones. Because a page frame contains 32768 bits, in 32-bit
architectures the pidmap_array bitmap is stored in a single page. In 64 bit architectures, however, additional
pages can be added to the bitmap when the kernel assigns a PID number too large for the current bitmap size.
These pages are never released.
Linux associates a different PID with each process or lightweight process in the system. As we shall see later
in this chapter, there is a tiny exception on multiprocessor systems. This approach allows the maximum flexibility,
because every execution context in the system can be uniquely identified.
On the other hand, Unix programmers expect threads in the same group to have a common PID. For instance,
it should be possible to send a signal specifying a PID that affects all threads in the group. In fact, the POSIX 1003.1c
standard states that all threads of a multithreaded application must have the same PID.
To comply with this standard, Linux makes use of thread groups. The identifier shared by the threads is the PID
of the thread group leader, that is, the PID of the first lightweight process in the group; it is stored in the tgid field
of the process descriptors. The getpid() system call returns the value of tgid relative to the current process instead of
the value of pid, so all the threads of a multithreaded application share the same identifier. Most processes belong
to a thread group consisting of a single number; as thread group leaders, they have the tgid field equal to the pid
field, thus the getpid() system call works as usual for this kind of process.
Later, we will show you how it is possible to derive a true process descriptor pointer efficiently from its respective
PID. Efficiency is important because many system calls such as kill() use the PID to denote the affected process.
process descriptor; therefore, even lightweight processes, which share a large portion of their kernel
data structures, have their own task_struct structures.
The strict one-to-one correspondence between the process and process descriptor makes the 32 bit
address of the task_struct a useful means for the kernel to identify processes. These addresses are referred
to as process descriptor pointers. Most of the references to processes that the kernel makes are through
process descriptor pointers.
On the other hand, Unix-like operating sytems allow usres to identify processes by means of a number
called the Process ID (or PID), which is stored in the pid field of the process descriptor. PIDs are numbered
sequentially: the PID of a newly created process is normally the PID of the previously created process
increased by one. Of course, there is an upper limit on the PID values; when the kernel reaches such limit,
it must start recycling the lower, unused PIDs. By default, the maximum PID number is 32767 (
PID_MAX_DEFAULT - 1); the system administrator may reduce this limit by writing a smaller value into
the /proc/sys/kernel/pid_max file. In 64-bit architectures, the system administrator can enlarge the
maximum number up to 4194303.
When recycling PID numbers, the kernel must manage a pidmap_array bitmap that denotes which are the
PIDs currently assigned and which are the free ones. Because a page frame contains 32768 bits, in 32-bit
architectures the pidmap_array bitmap is stored in a single page. In 64 bit architectures, however, additional
pages can be added to the bitmap when the kernel assigns a PID number too large for the current bitmap size.
These pages are never released.
Linux associates a different PID with each process or lightweight process in the system. As we shall see later
in this chapter, there is a tiny exception on multiprocessor systems. This approach allows the maximum flexibility,
because every execution context in the system can be uniquely identified.
On the other hand, Unix programmers expect threads in the same group to have a common PID. For instance,
it should be possible to send a signal specifying a PID that affects all threads in the group. In fact, the POSIX 1003.1c
standard states that all threads of a multithreaded application must have the same PID.
To comply with this standard, Linux makes use of thread groups. The identifier shared by the threads is the PID
of the thread group leader, that is, the PID of the first lightweight process in the group; it is stored in the tgid field
of the process descriptors. The getpid() system call returns the value of tgid relative to the current process instead of
the value of pid, so all the threads of a multithreaded application share the same identifier. Most processes belong
to a thread group consisting of a single number; as thread group leaders, they have the tgid field equal to the pid
field, thus the getpid() system call works as usual for this kind of process.
Later, we will show you how it is possible to derive a true process descriptor pointer efficiently from its respective
PID. Efficiency is important because many system calls such as kill() use the PID to denote the affected process.
相关文章推荐
- INNO安装卸载自动结束进程插件使用
- Inno Setup 在安装程序开始前和卸载程序开始前,检查并关闭运行的进程
- INNO:检测程序是否已经安装,是则弹出卸载提示。
- Inno Setup 安装、卸载前检测进程或服务
- 断点续传2
- 断点续传
- Python_编程特色
- 5.2 模型表示
- LeetCode Maximum Gap
- 线程池ThreadPoolExecutor使用简介(转)
- 在终端下使用Git上传本地代码至GitHub
- Lesson2 Square number
- aps clang: error: linker command failed with exit code 1 (use -v to see invocation)
- Codeforces Round #329 (Div. 2) A 2Char
- 这一页干的真多...
- 第九周学习报告
- *LeetCode-Longest Increasing Subsequence
- 黑马程序员-Java I/O流(一)-IO流概述、字符流、字节流、流操作规律
- Linux日志处理
- Vim 学习资料