目录
进程=一大堆内核数据结构(task_struct)+代码和数据
CPU怎么区分进程和线程?CPU不区分,在Linux中线程<=执行流<=进程,<就是线程,=就是进程(只有一个)
线程:是进程的一个执行分支,线程的执行粒度,要比进程要细
1.Linux中线程如何理解
地址空间是进程的资源窗口
多个PCB指向同一块地址空间,分配实现不同的代码
进程=一大堆内核数据结构(task_struct)+代码和数据
Linux实现方案:
在Linux中,线程在进程“内部”执行,线程在进程的地址空间运行?(为什么?)
任何执行流要执行,都要有资源!地址空间是进程的资源窗口
在Linux中,线程的执行粒度(粗细程度)要比进程要更细?线程执行进程代码的一部分
你所拥有的资源是和其他执行流共享的
不同系统对于线程的概念是一样的,但是对于线程的实现方案是不一样的
2.重新定义线程和进程
什么是线程?
我们认为,线程是操作系统调度的基本单位
重新理解进程?
内核观点:进程是承担分配系统资源的基本实体(操作系统中分配资源的方式是以进程为单位分配),相当于分配了村长管理一个村大小事情,而进程负责管理这一片的资源分配
进程被调度真正意义上是进程中的一个执行流资源被CPU执行而已,不是整个进程被调度
进程与线程之间的关系?
执行流也是一种资源
进程是包含线程的,因为进程是承担分配系统资源的基本实体,线程就是进程内部的一种执行流资源
资源解释一切。
如何理解我们以前的进程?
操作系统以进程为单位,给我们分配资源,只不过我们当前的进程内部,只有一个执行流!
因此理论上,可以认为,一个执行流是我们进程的特殊情况。
对线程进行先描述再组织
在大多数操作系统教程中,用struct tcb(thread ctrl block)对线程进行,描述组织
但是在Linux中,复用进程数据结构和管理方法,用struct task_struct------模拟线程
结论:Linux没有真正意义上的线程,而是用“进程(内核数据结构)”模拟线程
这极大降低维护成本和开发
CPU怎么区分进程和线程?
CPU不区分,在Linux中线程<=执行流<=进程,<就是线程,=就是进程,这里比较的是占据的资源大小
轻量级进程
Linux中的执行流,也被称为轻量级进程(执行流<=进程)
内核中时没有很明确的线程的概念的,内核只有轻量级进程的概念,因此也不会给我们提供线程的系统调用,只会给我们提供轻量级的系统调用
pthread线程库
pthread线程库是Linux程序员在应用层开发的。
它对轻量级进程接口进行封装,为用户提供直接线程的接口
几乎所有的Linux平台,都是默认带这个库的!
Linux中编写多线程代码需要使用第三方pthread库
生活体现
进程就像一个大家庭,每一个线程就对应着一个家庭成员,在一个家庭构成里,每一个人都领着一个自己的小任务,但每一个人都有共同的任务(为了把生活过好),资源=家里的物品都是大家共享的
一个家庭里只有一个人==一份资源只有一个执行流
创建一个进程就是申请资源,摧毁一个进程就是把资源全部干掉
3.重谈地址空间
CPU中的CR3寄存器,保留页表地址,同样的也有寄存器保存进程的pcb地址
页框和页帧
页框(page frame)是指内存中被划分出的固定大小的物理块,它们用来存储虚拟内存空间中的数据或代码。页框的大小通常是2的幂次方,比如4KB、8KB等,这样可以方便地进行地址映射和管理。
而页帧(page)则是指虚拟内存空间中被划分出的固定大小的逻辑块,它们用来存储进程的数据或代码。页帧的大小也通常是2的幂次方,与页框的大小相同。
操作系统会将虚拟内存空间按照页帧的大小进行划分,并且将每个页帧映射到对应的页框上。当进程需要访问一个虚拟地址时,操作系统会将该地址转化为对应的页帧号,并通过页表查询得到对应的页框号,最终将数据从页框中读取或写入。
总之,页框是物理内存中的一部分,页帧是虚拟内存中的一部分,它们之间的映射关系由操作系统管理。
虚拟到物理地址的转化
虚拟内存的32位:第一个数10索引页目录,第二个数10索引二级页表找到页框,第三个数12索引偏移量(页框大小4kb),这样就能找到物理内存。
最多有1024个二级页表(4kb*1024),整体计数一个进程中页表占据的大小最多1M左右,但是大多数情况下,不会所有二级页表都存在,但是页目录必须存在,保留在CPU的CR3寄存器中,还有一个CR2寄存器记录的是引起缺页中断或者异常的虚拟地址,在准备工作就绪后,再取出里面的地址找到物理内存
类型是给CPU看的,CPU内有识别内置类型的寄存器,自定义类型呢?它也是由一堆内置类型构成的,空类也有一个占位符(1字节)
起始地址+类型=起始地址+偏移量(X86的特点)
线程目前分配资源,本质就是分配地址空间范围(分配资源、代码和数据)
4.Linux线程周边的概念
为什么线程比进程要更轻量化?(生命周期)
a.创建和释放更加轻量化(生死)
b.切换更加轻量化(运行),只需要切换线程的上下文,不需要切换地址空间和页表、cache等等
线程内的切换不需要重新cache数据(由冷变热,重新缓存),cache的速度介于CPU与内存之间
cache大小(随配置改变)
cat /proc/cpuinfo
线程的时间片
一个进程内的多个线程共享时间片,一般情况下都是均分
线程是有身份的
创建的进程的第一个执行流是主线程,后面创建的线程是新线程,操作系统能够区分是进程内线程的切换,还是进程之间的切换。主线程内有一个总时间片和均分时间片,新线程中只有一个均分时间片,总时间片跟着均分时间片一起减少
线程的优缺点
优点
创建一个新线程的代价要比创建一个新进程小得多
与进程之间的切换相比,线程之间的切换需要操作系统做的工作要少很多
线程占用的资源要比进程少很多
能充分利用多处理器的可并行数量 在等待慢速I/O操作结束的同时,程序可执行其他的计算任务
计算密集型应用,为了能在多处理器系统上运行,将计算分解到多个线程中实现
I/O密集型应用,为了提高性能,将I/O操作重叠。线程可以同时等待不同的I/O操作。
计算密集型应用时,一般有多少个CPU就创建多少个线程(因为线程切换也是有成本的)
I/O密集型应用时,可以多创建线程,因为它们等待的时间可以重叠
缺点
性能损失(次要)
一个很少被外部事件阻塞的计算密集型线程往往无法与共它线程共享同一个处理器。如果计算密集型 线程的数量比可用的处理器多,那么可能会有较大的性能损失,这里的性能损失指的是增加了额外的 同步和调度开销,而可用的资源不变。
因为缺乏访问控制(线程共享大部分资源,一个线程出问题可能会影响其他线程,导致壮性降低),所以健壮性降低。
就像公司里的一个组里,一个人删库跑路了,会影响这个组嘛?
一个线程一旦出问题,整个进程都会挂掉。比如一个线程中出现除零错误或者野指针问题,本质就是进程收到信号(信号是直接发送给进程的,信号是独立于进程之外的执行流),可以理解成每一个线程都要执行信号的默认处理方法(不改变的情况下)
有进程信号,但没有线程信号
健壮性降低
编写多线程需要更全面更深入的考虑,在一个多线程程序里,因时间分配上的细微偏差或者因共享了 不该共享的变量而造成不良影响的可能性是很大的,换句话说线程之间是缺乏保护的。
缺乏访问控制
进程是访问控制的基本粒度,在一个线程中调用某些OS函数会对整个进程造成影响。
编程难度提高
编写与调试一个多线程程序比单线程程序困难得多(比如出现错误时,无法快速找到出错的地方)
线程异常
单个线程如果出现除零,野指针问题导致线程崩溃,进程也会随着崩溃
线程是进程的执行分支,线程出异常,就类似进程出异常,进而触发信号机制,终止进程,进程终止,该 进程内的所有线程也就随即退出
线程用途
合理的使用多线程,能提高CPU密集型程序的执行效率
合理的使用多线程,能提高IO密集型程序的用户体验(如生活中我们一边写代码一边下载开发工具,就是多线程运行的一种表现)
进程和线程
进程是资源分配的基本单位
线程是调度的基本单位
线程共享进程数据,但也拥有自己的一部分数据:
线程ID
线程最重要的两个性质(线程的动态特性)——线程独占的资源
《
线程上下文和栈
***一组寄存器(线程的上下文数据)独立的上下文,能够体现出线程是被独立调度的
***栈(线程在调度时,有自己独立的栈结构),独立的栈结构,可以体现线程之间运行时,不会出现执行流错乱问题(前提代码没问题)
》
errno
信号屏蔽字
调度优先级
###进程的多个线程共享 同一地址空间,因此Text Segment(代码区)、Data Segment(数据区)都是共享的,如果定义一个函数,在各线程 中都可以调用,如果定义一个全局变量,在各线程中都可以访问到,除此之外,各线程还共享以下进程资源和环境:
文件描述符表
每种信号的处理方式(SIG_ IGN、SIG_ DFL或者自定义的信号处理函数)
当前工作目录
用户id和组id
样例代码
两个死循环,能否在同一个执行流里面跑呢?不可能
#include<iostream>
#include<pthread.h>
#include<unistd.h>
void* thread_run(void*arg)
{
while(1)
{
std::cout<<"i am new thread"<<std::endl;
sleep(1);
}
return nullptr;
}
int main()
{
pthread_t th;
pthread_create(&th,nullptr,thread_run,nullptr);
while(1)
{
std::cout<<"i am old thread"<<std::endl;
sleep(1);
}
return 0;
}
~
~