Linux Process VS Thread VS LWP
Process
program
program==code+data;
一个进程可以对应多个程序,一个程序也可以变成多个进程。程序可以作为一种软件资源长期保存，以文件的形式存放在硬盘
process:
- 相应的程序+CPU上下文+一组系统资源
- 动态性, 独立性, 并发性
- 一个CPU，任何时刻最多只能有一个进程去使用它
process VS thread
- 进程的资源分配的基本单位，是分配资源的抽象:进程把一组相关资源组合起来，构成了一个资源平台，或者说资源环境，包括运行上下文，内存地址空间，打开的文件等
- 线程是系统调度的基本单位，是执行流程的抽象:进程上的一条执行流程，就是线程
- 早期不区分这两者,一个进程,既指它的资源平台,又指它的执行流程,后来把二者分开,所以进程=线程+资源平台
- 在嵌入式系统中，不使用process或thread，而是使用task，具体这个task是什么得看情况,VxWorks,ucosII,Jbed里是thread; linux里是process
Linux Process Types
A process is an instance of a computer that is currently being executed. Associated with a process is a variety of attributes (ownership, nice value, and SELinux context , to name a few) that extend or limit its ability to access resources on the computer. In Linux, there are 3 types processes: User Process, Daemon Process, Kernel Process
User Process
A user process is one that is initiately by a regular user account and runs in user space. Unless it is run in a way that gives the process special permissions, an ordinary user process has no special access to the processor or to files on the system that don’t belong to the user who launched the process.
Daemon Process
A daemon process is an application that is designed to run in the background, typically managing some kind of ongoing service. They run in user space
System often start daemons at boot time and have them run continuously until the system is shut down. Daemon can also be started or stopped on demand, set to run at particular system run levels, and in some cases signaled to reload configuration information on the fly.
Although daemon processes are typically managed as services by the root user,daemon processes often run as non-root users by a user account that is dedicated to the services.
Kernel Process
A Kernel process executes only in kernel space. They are similar to daemon processes. The primary different is that kernel processes have full access to kernel data structures, which makes them more powerful than daemon processes, which run in user space. Kernel processes are not as flexible as daemon processes. You can change the behavior of a daemon process by changing configuration files and reloading the service, however, changing kernel processes may require recompiling the kernel.
Linux Process States
When a process is created, the system assigns it a state. The state field of the process descriptor describes the current state of the process. The value of the state field is usually set with a simple assignment:
8 primary states of a process in Linux:
- TASK_RUNNING(ready/waiting)
- TASK_RUNNING(running)
- TASK_INTERRUPTIBLE(interruptible sleep/blocked)
- TASK_UNINTERRUPTIBLE(uninterruptible sleep/blocked)
- TASK_STOPED(stoped)
- TASK_ZOMBIE(zombie)
- TASK_DEAD(dead)
- TASK_TRACED(traced)
3 additional states of a process in Linux：
Two additional states are available for processes in systems that support virtual memory. In both of these states, processes are "stored" on secondary memory (typically a hard disk)
- Swapped out and waiting (Also called suspended and waiting.)
A process may be swapped out, that is, removed from main memory and placed on external storage by the scheduler. From here the process may be swapped back into the waiting state. - Swapped out and (interruptible/uninterruptible)blocked (Also called suspended and blocked.)
Processes that are blocked may also be swapped out. In this event the process is both swapped out and blocked, and may be swapped back in again under the same circumstances as a swapped out and waiting process.
Q: Stopped state VS Terminated state
A: Stopped means the process has received one of SIGSTOP / SIGTSTP / SIGTTIN / SIGTTOU, and won't do anything much until it receives a SIGCONT.
Zombie means the underlying program is no longer executing, but the process remains in the process table as a zombie process until its parent process calls the wait system call to read its exit status, at which point the process is removed from the process table, finally ending the process's lifetime. If the parent fails to call wait, this continues to consume the process table entry (concretely the process identifier or PID), and causes a resource leak.
Q: Interruptible Sleep State VS Uninterruptible Sleep state
A:Interruptible Sleep means the process is waiting wither for a particular time slot or a particular event to occur. Once one of those things occurs, the process will come out of Interruptible Sleep.
An Uninterruptible Sleep state is one that won’t handle a signal right away. It will wake only as a result of a waited-upon resource becoming available or after a time-out occurs duing that wait(if the time – out is specified when the process is put to sleep). It is mostly used by device drivers waiting for disk or network I/O. When the process is sleeping uninterruptibly, signals accumulated during the sleep are noticed when the process returns from system call or trap.
User Thread
- Belongs to a user process
- Managed by itself
- Shares address space, open files, user credentials etc . in the same process
- Privatize program counter, stack, and register context etc.
- Unindependently scheduled
- Extremely inexpensive, consume no kernel resource.
- Useful to realize concurrence inside a user-process
- pthread_create()
LWP
Light Weight Process--Kernel-supported user thread
- Belongs to a user process
- Managed by kernel
- Shares address space, open files, user credentials etc . in the same process
- In addition to program counter, stack, and register context etc. needs to maintain some user state
- Independently scheduled
- Expensive to block
- Useful for independent tasks with little interaction with other lightweight processes
- clone()
Kernel Thread
- Need not be associated with a user process
- Managed by kernel
- Shares kernel text, global data etc.
- Privatize program counter , kernel stack register context etc.
- Independently scheduled
- Inexpensive
- Require space only for kernel stack and register context
- Fast context switching as no memory mappings are to be flushed
- Useful for operations such as asynchronous I/O
- Request can be synchronously handled by the kernel thread
- fork()/vfork()
