您的位置:首页 > 汽车 > 新车 > 童美童程儿童编程价格_张家界seo优化首选_seo推广外包企业_写软文是什么意思

童美童程儿童编程价格_张家界seo优化首选_seo推广外包企业_写软文是什么意思

2024/11/15 16:10:19 来源:https://blog.csdn.net/2301_79697943/article/details/142466903  浏览:    关键词:童美童程儿童编程价格_张家界seo优化首选_seo推广外包企业_写软文是什么意思
童美童程儿童编程价格_张家界seo优化首选_seo推广外包企业_写软文是什么意思

目录

前言:

代码现象

快速理解该现象

理解部分细节问题

细节1 拷贝和独立性

细节2 如何理解地址空间

细节3 为什么存在地址空间

细节4 如何进一步理解页表和写时拷贝


前言:

本文介绍的是有关地址空间,咱们的介绍的大体思路是,先直接看现象,通过现象我们引入地址空间的概念,然后是简单的介绍地址空间,如何理解地址空间等,在往后的学习中,我们大概会介绍地址空间3 - 4次,因为地址空间有很多内容一次性还介绍不完,并且在本文中,我们能够理解之前颠覆代码三观的函数——fork(),现在就进入正题。


代码现象

目前我们对于地址空间没有明确的概念,所以先来看这样一段代码:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include<sys/types.h>int g_val =100;
int main()
{pid_t id = fork();if(id == 0){int count = 1;while(count){printf("g_val is %d,&g_val = %p\n",g_val,&g_val);sleep(1);if(count == 5)g_val = 200;count++;}}else{while(1){printf("g_val is %d,&g_val = %p\n",g_val,&g_val);sleep(1);}}return 0;
}

代码的意思是,我们创建一个父进程之后,在父进程里面创建一个子进程,子进程要完成的工作是打印g_val和它的地址,当count到5的时候就修改g_val,但是后续还是要一直打印,父进程要做的工作就是一直打印g_val和g_val的地址。

现象如下:

打印5秒之后,g_val的值如愿以偿的被修改了,此时让父进程打印的时候,我们发现一个怪事,打印的时候为什么父进程中的g_val没有变化呢?我们在进程部分知道父进程的数据是和子进程共享的,但是此时,父进程的数据被子进程修改了,父进程居然无动于衷?

现在的现象就是:一个变量,地址没有变化,但是拥有两个不同的值。

我们一会儿要理解的就是该现象,该现象理解了之后,我们同时就能理解fork函数的返回值是怎么回事了。


快速理解该现象

我们如果想要快速理解该现象,就需要引入两个概念,一个是物理内存,一个是虚拟内存

物理内存很好理解,即我们平常买的,比如三星SSD 990Pro内存条,就是物理内存,数据是实打实的在里面加载了的,但是虚拟内存是怎么回事呢?

我们平常写下的对某个对象取地址,本质上都是在虚拟内存层面上进行操作,并不是在物理内存上,那么上面代码写的,&g_val本质上就是个虚拟地址!

那么虚拟地址(内存)如何和物理地址(内存)进行联系呢?

这里就需要引出地址空间的概念了,这是地址空间的形象图,我们在语言学习阶段,最多涉及到的只有malloc空间在堆上,局部变量在栈上等概念,我们没有系统的学习,这里我们会深入一点点,为什么存在地址空间?地址空间是什么?有什么用?这是我们需要知道的。

我们最开始的问题是,虚拟内存如何和物理内存进行联系的,这个过程有地址空间的一份功劳,我们从名字来看,地址空间,地址,空间,容易想到这是一块空间,空间里面充满了地址这种描述,实际上确实是这样的,地址空间在源码中的名字叫做mm_struct,更深层次的我们不追究,而我们最开始说的,task_struct,mm_struct是嵌套在里面的。

通过我们刚才的描述,mm_struct里面充满了地址,那么是谁的地址呢?

由图我们知道,由堆区的地址,栈的地址,初始化数据的地址等,但是同时,不是所有的地址我们都是可以访问的,像内核空间的地址,我们知道,但是是无法访问的。一个空间里面充满了地址,可以用什么变量表示呢?结构体对吧!

所以地址空间本质上就是结构体,进程通过地址空间的所有地址来找到物理内存中对应的数据。

那么问题又来了,里面不是都存的虚拟地址吗,怎么通过虚拟地址来找物理地址呢?

这时候,页表就该引入了。

页表,最直观的就是:

最最最简单的页表就是这样,每一行的元素存在映射关系,既然是提到了映射关系,相信不少同学都明白了,映射嘛,左边是虚拟地址,右边是物理地址,这就是OS通过页表,地址空间等,链接了虚拟内存和物理内存的方法。

当然了,页表还有许多没有介绍的,在后续文章中会介绍的。

现在就得出结论:虚拟内存和物理内存的联系是通过页表,地址空间,从地址空间得到虚拟内存,在页表存在虚拟内存和物理内存的映射的关系来找到对应的数据,这是OS中找数据的方法。

现在只是知道了找数据,但是我们不清楚了找数据之后,为什么同样的地址会有两份结果,那么虚拟地址都是一样的,映射关系可以不一样吗?

大体图就是这样,父进程和子进程得到的虚拟地址是一样的,但是呢,当子进程对父进程中的某个数据发生了修改,此时就会发生写时拷贝,即在物理内存层面拷贝一个该数据,子进程指向该数据即可。

以上是对文章开头代码的简单理解。


理解部分细节问题

细节1 拷贝和独立性

我们重新理解一下,什么是进程的独立性?

从上文代码可以看出来,我们虽然在父进程里面创建了一个子进程,但是数据在物理内存中却不是同一个,通过写时拷贝再次印证了进程的独立性问题。

既然子进程修改父进程中的数据,会导致发生写时拷贝,那么在物理内存层面,为什么不全部拷贝一份呢?

在C++的类和对象中,存在按需实例化的语法,在OS层面上也是同理,从按需实例化的角度来看,子进程需要使用到父进程中的什么数据,如果发生了改变才会有写时拷贝,从地址空间的角度来看,地址空间的内核部分,是用户层面无法调用的,所以没有必要发生拷贝复制,所以按需实例化的方式,成功的可以节省一定的空间。

细节2 如何理解地址空间

在小学的时候,我们和同桌不妨都有过三八线的经历,这个动作的本质就是在划分区域,划分区域涉及到的对象有自己拥有的区域,桌子这一整个对象,所以这个动作可以分为,A拥有自己的空间,B拥有自己的空间,所有空间加起来就是桌面的大小。

那么我们不妨将桌面的整个空间理解为OS内核,里面存在的所有地址空间,都是一个一个的结构体,那么为了区域划分,结构体里面肯定是需要不同的变量来表示区域的开始 结束的,在地址空间这里,我们不妨简单看一下源码:

struct mm_struct {struct vm_area_struct * mmap;		/* list of VMAs,指向线性区对象的链表头部 */struct rb_root mm_rb;                   /* 指向线性区对象的红黑树*/struct vm_area_struct * mmap_cache;	/* last find_vma result 指向最近找到的虚拟区间 */
#ifdef CONFIG_MMU /*用来在进程地址空间中搜索有效的进程地址空间的函数*/unsigned long (*get_unmapped_area) (struct file *filp,unsigned long addr, unsigned long len,unsigned long pgoff, unsigned long flags);
/*释放线性区的调用方法*/void (*unmap_area) (struct mm_struct *mm, unsigned long addr);
#endifunsigned long mmap_base;		/* base of mmap area ,内存映射区的基地址*/unsigned long task_size;		/* size of task vm space */unsigned long cached_hole_size; 	/* if non-zero, the largest hole below free_area_cache */unsigned long free_area_cache;		/* first hole of size cached_hole_size or larger */pgd_t * pgd;                            /* 页表目录指针*/atomic_t mm_users;			/* How many users with user space?,共享进程的个数 */atomic_t mm_count;			/* How many references to "struct mm_struct" (users count as 1),主使用计数器,采用引用计数,描述有多少指针指向当前的mm_struct */int map_count;				/* number of VMAs ,线性区个数*/struct rw_semaphore mmap_sem;spinlock_t page_table_lock;		/* Protects page tables and some counters,保护页表和引用计数的锁 (使用的自旋锁)*/struct list_head mmlist;		/* List of maybe swapped mm's.	These are globally strung* together off init_mm.mmlist, and are protected* by mmlist_lock*/unsigned long hiwater_rss;	/* High-watermark of RSS usage,进程拥有的最大页表数目 */unsigned long hiwater_vm;	/* High-water virtual memory usage ,进程线性区的最大页表数目*/unsigned long total_vm, locked_vm, shared_vm, exec_vm;unsigned long stack_vm, reserved_vm, def_flags, nr_ptes;unsigned long start_code, end_code, start_data, end_data;     /*维护代码区和数据区的字段*/unsigned long start_brk, brk, start_stack;       /*维护堆区和栈区的字段*/unsigned long arg_start, arg_end, env_start, env_end;  /*命令行参数的起始地址和尾地址,环境变量的起始地址和尾地址*/unsigned long saved_auxv[AT_VECTOR_SIZE]; /* for /proc/PID/auxv *//** Special counters, in some configurations protected by the* page_table_lock, in other configurations by being atomic.*/struct mm_rss_stat rss_stat;struct linux_binfmt *binfmt;cpumask_t cpu_vm_mask;/* Architecture-specific MM context */mm_context_t context;/* Swap token stuff *//** Last value of global fault stamp as seen by this process.* In other words, this value gives an indication of how long* it has been since this task got the token.* Look at mm/thrash.c*/unsigned int faultstamp;unsigned int token_priority;unsigned int last_interval;unsigned long flags; /* Must use atomic bitops to access the bits */struct core_state *core_state; /* coredumping support */
#ifdef CONFIG_AIOspinlock_t		ioctx_lock;struct hlist_head	ioctx_list;
#endif
#ifdef CONFIG_MM_OWNER/** "owner" points to a task that is regarded as the canonical* user/owner of this mm. All of the following must be true in* order for it to be changed:** current == mm->owner* current->mm != mm* new_owner->mm == mm* new_owner->alloc_lock is held*/struct task_struct *owner;
#endif#ifdef CONFIG_PROC_FS/* store ref to file /proc/<pid>/exe symlink points to */struct file *exe_file;unsigned long num_exe_file_vmas;
#endif
#ifdef CONFIG_MMU_NOTIFIERstruct mmu_notifier_mm *mmu_notifier_mm;
#endif
};

里面存在的字段,如start_code等,都是地址空间里面不同区域的划分。

这里我们可以得出结论,地址空间本质就是内核中的一个一个的结构体,每个进程都拥有自己的地址空间

细节3 为什么存在地址空间

结合细节2,我们以大富翁的概念来结束进程的理解,大富翁的总资产是10亿,对于不同的孩子,他都是说我有10亿,你们看着要就行,但是大富翁肯定是会给儿女不同的零花钱什么的。这里面,大富翁就是OS,地址空间就是零花钱,不同的儿女对应不同的进程。

那么为什么存在地址空间呢?它存在的意义是什么?

从内存层面上来讲,如何程序直接在物理内存上开辟空间,那必然是杂乱无章,因为哪里有空间就开在哪里,操作系统管理起来就十分麻烦,这是无序的,有了地址空间这个结构,地址空间里面存储的都是进程里面的地址信息,那么集合管理在一个结构体里面,从有序的角度去看待地址,而非在物理内存里面无序的查找。所以地址空间可以让无需变成有序。

从管理内存和进程的角度来看,地址空间的存在可以让进程管理模块和进程管理模块解耦,如果没有地址空间,那么进程是直接链接在物理内存上的,那么进程里面申请了一个变量,在物理内存上就一定会申请空间,势必空间会不太够用,但是有地址空间,即便申请了,但是没有用,页表那里甚至可以先不映射,如果使用了,再映射即可。所以管理进程和内存,可以通过页表来解耦,而不是直接让进程和内存完全绑定在一起。

从安全问题上来看,我们之前写代码的时候,如果出现了非法请求,比如野指针访问,进程就会被直接杀死,这是因为地址空间已经划分好了空间,如果访问的地址超过了这个空间,就是非法访问,OS层面检测出越界,肯定就直接杀死该进程了。这是一种对物理内存的保护,再比如,一对父子,子如果直接拥有钱,自由支配,不免的会买不利于成长的玩具,但是父如果作为中间商,对钱进行管理,子想要买,必须通过父这一层,此时,子想买扑克牌,父制止,这个就是对非法请求的拦截,也是保护了整个内存的运作。

细节4 如何进一步理解页表和写时拷贝

我们看一段简单的代码:

const char* str = "abcdefg";
str = 'A';

为什么str不能被修改呢?我们知道它是const类型的。

但是为什么const类型就不能被修改呢?因为在页表里面还存在数据的权限,rwx。

对于str来说,是只读的,所以对应的权限是r,代码一般也是只读的。所以即便页表对应到了该数据,但是页表中记录的权限仍然是r,没有w,那么它就无法写。

对于页表中是如何映射的我们先不管,里面涉及到了cpu中的CR3和MMU,后面详细介绍。

当OS在页表中查找数据时,如果没有该数据,就会发生缺页中断,如果数据需要写时拷贝,就会发生写时拷贝,对于数据,如果上面的两种情况都不满足,才会引入异常。

这里对于虚拟地址也带一嘴,虚拟地址哪里来的呢?为什么地址空间一来就有地址呢?这是因为程序本身就有地址,我们使用指令:objdump -S 可执行文件名

0000000000001000 <_init>:1000:	f3 0f 1e fa          	endbr64 1004:	48 83 ec 08          	sub    $0x8,%rsp1008:	48 8b 05 d9 2f 00 00 	mov    0x2fd9(%rip),%rax        # 3fe8 <__gmon_start__@Base>100f:	48 85 c0             	test   %rax,%rax1012:	74 02                	je     1016 <_init+0x16>1014:	ff d0                	call   *%rax1016:	48 83 c4 08          	add    $0x8,%rsp101a:	c3                   	ret    Disassembly of section .plt:0000000000001020 <.plt>:1020:	ff 35 8a 2f 00 00    	push   0x2f8a(%rip)        # 3fb0 <_GLOBAL_OFFSET_TABLE_+0x8>1026:	f2 ff 25 8b 2f 00 00 	bnd jmp *0x2f8b(%rip)        # 3fb8 <_GLOBAL_OFFSET_TABLE_+0x10>102d:	0f 1f 00             	nopl   (%rax)1030:	f3 0f 1e fa          	endbr64 1034:	68 00 00 00 00       	push   $0x01039:	f2 e9 e1 ff ff ff    	bnd jmp 1020 <_init+0x20>103f:	90                   	nop1040:	f3 0f 1e fa          	endbr64 1044:	68 01 00 00 00       	push   $0x11049:	f2 e9 d1 ff ff ff    	bnd jmp 1020 <_init+0x20>104f:	90                   	nop1050:	f3 0f 1e fa          	endbr64 1054:	68 02 00 00 00       	push   $0x21059:	f2 e9 c1 ff ff ff    	bnd jmp 1020 <_init+0x20>105f:	90                   	nopDisassembly of section .plt.got:0000000000001060 <__cxa_finalize@plt>:1060:	f3 0f 1e fa          	endbr64 1064:	f2 ff 25 8d 2f 00 00 	bnd jmp *0x2f8d(%rip)        # 3ff8 <__cxa_finalize@GLIBC_2.2.5>106b:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)Disassembly of section .plt.sec:0000000000001070 <printf@plt>:1070:	f3 0f 1e fa          	endbr64 1074:	f2 ff 25 45 2f 00 00 	bnd jmp *0x2f45(%rip)        # 3fc0 <printf@GLIBC_2.2.5>107b:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)0000000000001080 <sleep@plt>:1080:	f3 0f 1e fa          	endbr64 1084:	f2 ff 25 3d 2f 00 00 	bnd jmp *0x2f3d(%rip)        # 3fc8 <sleep@GLIBC_2.2.5>108b:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)0000000000001090 <fork@plt>:1090:	f3 0f 1e fa          	endbr64 1094:	f2 ff 25 35 2f 00 00 	bnd jmp *0x2f35(%rip)        # 3fd0 <fork@GLIBC_2.2.5>109b:	0f 1f 44 00 00       	nopl   0x0(%rax,%rax,1)Disassembly of section .text:

就可以看到对应的程序地址了,当然,了解即可。

地址空间到这里就粗略的收场了,后面会介绍的。

再回归到最开始的问题,为什么fork的返回值会有“两个”,你理解了吗?


感谢阅读!

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com