你的浏览器版本过低,可能导致网站不能正常访问!
为了你能正常使用网站功能,请使用这些浏览器。

抽象建模的角度来对Linux进程描述符进行解读

[复制链接]
gaosmile 发布时间:2020-4-26 17:54
[导读] 内核是怎么工作的,首先要理解进程管理,进程调度,本文开始阅读进程管理部分,首先从进程的抽象描述开始。抽象是软件工程的灵魂,而对于Linux操作系统而言,更是将抽象思想体现的淋漓尽致。本文从抽象建模的角度来对Linux进程描述符进行个人解读,同时也参考了内核文档,一些网络信息。
7 J  |1 |1 z) T+ y0 f( p
注:代码基于linux-5.4.31,是一个最新的长期支持稳定版本。
3 x9 L) y( O% S) ~5 o( @
整理匆忙,限于水平,文章中错误一定很多,真诚恳请有这方面擅长的朋友帮忙指出,不甚感激!

1 R  L8 [" z9 Q* z) r
进程的基本概念
, _4 t2 t! R8 k( E9 [进程 or 线程 or 任务?
# A  X- D3 f3 }* S5 W9 E6 ^: D" G; N9 m; `  f3 _  Y
7 l+ ~9 K5 Y; h# o1 p4 I! M* z
进程:进程是一个正在运行的程序实例,由可执行的目标代码组成,通常从某些硬媒介(如磁盘,闪存等)读取并加载到内存中。但是,从内核的角度来看,涉及很多相关的工作内容。操作系统存储和管理有关任何当前正在运行的程序的其他信息:地址空间,内存映射,用于读/写操作的打开文件,进程状态,线程等。
7 A6 E+ P# T) T: M) G( }
进程是正在执行的计算机程序的实例。它包含程序代码及其当前活动。取决于操作系统(OS),进程可能由同时执行指令的多个执行线程组成。基于进程的多任务处理使您可以在使用文本编辑器的同时运行Java编译器。在单个CPU中采用多个进程时,使用了各种内存上下文之间的上下文切换。每个过程都有其自己的变量的完整集合。
( F- C" r( M$ G5 z
但是,在Linux中,如果不讨论线程(有时称为轻量级进程),进程的抽象是不完整的。根据定义,线程是流程中的执行上下文或执行流;因此,每个进程至少包含一个线程。包含多个执行线程的进程被称为多线程进程。一个进程中有多个线程可以进行当前编程,并且在多处理器系统上可以实现真正的并行性。
7 @5 b& h- I2 G) f
线程:则是某一进程中一路单独运行的程序,也就是说,线程存在于进程之中。一个进程由一个或多个线程构成,各线程共享相同的代码和全局数据,但各有其自己的堆栈。由于堆栈是每个线程一个,所以局部变量对每一线程来说是私有的。由于所有线程共享同样的代码和全局数据,它们比进程更紧密,比单独的进程间更趋向于相互作用,线程间的相互作用更容易些,因为它们本身就有某些供通信用的共享内存:进程的全局数据。

1 {; O- e& I1 e! Z+ {
线程是CPU利用率的基本单位,由程序计数器,堆栈和一组寄存器组成。执行线程是由计算机程序的分支分解为两个或多个同时运行的任务而产生的。线程和进程的实现因一个操作系统而异,但在大多数情况下,线程包含在进程内部。多个线程可以存在于同一进程中并共享资源(例如内存),而不同进程则不共享这些资源。同一进程中的线程示例是自动拼写检查和写入时自动保存文件。线程基本上是在相同内存上下文中运行的进程。线程在执行时可能共享相同的数据。线程图,即单线程与多线程

3 |0 D1 V4 v) A
任务:是最抽象的,是一个一般性的术语,指由软件完成的一个活动。一个任务既可以是一个进程,也可以是一个线程。简而言之,它指的是一系列共同达到某一目的的操作。与线程非常相似,不同之处在于它们通常不直接与OS交互。像线程池一样,任务不会创建自己的OS线程。一个任务内部可能有一个线程,也可能没有。例如,读取数据并将数据放入内存中。这个任务可以作为一个进程来实现,也可以作为一个线程(或作为一个中断任务)来实现。在RTOS中,一般会将调度的基本单元称为任务,比如freeRTOS,ucos,embOS等,在RTOS中没有进程的概念。
6 t9 s" Z8 _  ~2 A: t
进程
线程
进程是重量级的操作线程是轻量级操作
每个进程都有自己的内存空间线程共享它们所属的进程的内存空间
进程间的通信速度很慢,因为进程具有不同的内存地址线程间通信可能比进程间通信快,因为同一进程的线程与其所属的进程共享内存
进程之间的上下文切换开销大在同一进程的线程之间进行上下文切换的开销较低
进程不与其他进程共享内存线程与同一进程的其他线程共享内存
进程间通讯机制:
5 u! a0 T1 M5 Z( e% d
  • 管道(Pipe)及有名管道(named pipe):管道可用于具有亲缘关系进程间的通信,有名管道克服了管道没有名字的限制,因此,除具有管道所具有的功能外,它还允许无亲缘关系进程间的通信;
  • 信号(Signal):信号是比较复杂的通信方式,用于通知接受进程有某种事件发生,除了用于进程间通信外,进程还可以发送信号给进程本身;linux除了支持Unix早期信号语义函数sigal外,还支持语义符合Posix.1标准的信号函数 sigaction(实际上,该函数是基于BSD的,BSD为了实现可靠信号机制,又能够统一对外接口,用sigaction函数重新实现了signal 函数);
  • 报文(Message)队列(消息队列):消息队列是消息的链接表,包括Posix消息队列system V消息队列。有足够权限的进程可以向队列中添加消息,被赋予读权限的进程则可以读走队列中的消息。消息队列克服了信号承载信息量少,管道只能承载无格式字节流以及缓冲区大小受限等缺点。
  • 共享内存:使得多个进程可以访问同一块内存空间,是最快的可用IPC形式。是针对其他通信机制运行效率较低而设计的。往往与其它通信机制,如信号量结合使用,来达到进程间的同步及互斥。
  • 信号量(semaphore):主要作为进程间以及同一进程不同线程之间的同步手段。
  • 套接字(Socket):更为一般的进程间通信机制,可用于不同机器之间的进程间通信。起初是由Unix系统的BSD分支开发出来的,但现在一般可以移植到其它类Unix系统上:Linux和System V的变种都支持套接字。
    , ~. T4 T0 O) B
线程间的同步机制:为啥线程间没有讨论通讯机制?因为同一进程内的线程共享进程的资源。那么资源共享,则需要处理资源共享时的同步问题。
  • 互斥锁(mutex):通过锁机制实现线程间的同步。同一时刻只允许一个线程执行一个关键部分的代码。这部分代码常称为临界区。哪些可能是临界区呢?简言之,多个线程可能竞争访问的资源。以下一些函数是互斥锁的API函数。* s8 H# ?+ n6 R& T6 |( C5 y; ?8 d5 Z
int pthread_mutex_init(pthread_mutex_t *mutex,const pthread_mutex_attr_t *mutexattr);
& U6 a5 `5 `$ Iint pthread_mutex_lock(pthread_mutex *mutex);
0 M1 e8 O+ b1 Z" l+ cint pthread_mutex_destroy(pthread_mutex *mutex);4 V# O# R0 L2 g/ I- G
int pthread_mutex_unlock(pthread_mutex *
3 G, A3 R- W5 H
  • 全局条件变量(condition variable): 创建一些全局条件变量进行互斥访问控制。以下是其操作的基本接口函数:0 t; n5 c, A4 E
int pthread_cond_init(pthread_cond_t *cond,pthread_condattr_t *cond_attr);  
# a! N8 ^/ }0 s+ |, cint pthread_cond_wait(pthread_cond_t *cond,pthread_mutex_t *mutex);
8 @5 W4 |2 E- ~  B% nint pthread_cond_timewait(pthread_cond_t *cond,pthread_mutex *mutex,const timespec *abstime);
( z: H- Y4 {# S' D9 W! Cint pthread_cond_destroy(pthread_cond_t *cond);1 \7 w3 P3 }' E1 b3 M( _1 P  C
int pthread_cond_signal(pthread_cond_t *cond);
4 F* l+ U& l$ n+ U9 D3 G( i  mint pthread_cond_broadcast(pthread_cond_t *cond);

# I. n; |  _0 V0 [
  • 信号量(semaphore):如同进程一样,线程也可以通过信号量来实现通信,其基本操作接口API:3 T* j! g1 v- n
int sem_init (sem_t *sem , int pshared, unsigned int value);
6 m' {  m% Z  |2 d' ]) C! e% _int sem_wait(sem_t *sem);
" B) `. x5 O* D: C! _7 ]int sem_post(sem_t *sem);# Q8 E1 K- ]- _4 W7 l! s) [
int sem_destroy(sem_t *sem);
; y( [) Y1 f6 g  r4 n$ ~
" U5 U% K, L% |0 ~' I7 C. R
进程在内核中如何描述?
* |& v' Y7 S: i2 o% Y+ A0 }: g& O" m2 A9 \. F$ x& Y" |6 G; O; s2 s

8 p, Y; r4 ]9 \0 \* T
Linux中进程描述在./include/linux/sched.h中定义:
struct task_struct {% m$ w- I! ]! S
#ifdef CONFIG_THREAD_INFO_IN_TASK
3 h3 l4 {, M& I0 N3 o9 a0 N" M0 H /* 必须是首个元素  */
9 `% q9 }1 p, {3 a struct thread_info  thread_info;
' \7 D: D% j: |1 p0 K# j6 W#endif" s& q7 X  O' Q/ E! c5 G
/* -1 unrunnable, 0 runnable, >0 stopped: */3 h) X6 d( s8 |0 v1 M. }5 }: {0 ~$ F
volatile long   state;
2 ]" l4 \, w/ @; E# w" Y, v$ x# R/ X: b2 g8 u# R# |' U* G/ s: s; V
/* 前面是与调度密切相关的信息添加在这之前 */
, m3 o& ]9 R4 ]: ] randomized_struct_fields_start4 k- Y  O2 a$ [$ w

) o0 _+ R- C: O$ H7 L$ p void    *stack;" m4 ?5 C- B" }1 i
refcount_t   usage;2 L! w5 w* p+ s$ o7 c0 p/ _
/* Per task flags (PF_*), defined further below: */
8 J* i; D; x1 K, t! G' o unsigned int   flags;
4 E5 C  V# v+ I- B unsigned int   ptrace;* Q; _; o# Z! `  R; V9 d
.........0 h* H5 ~  ]! L7 D1 l8 ?" S
};
/ Z- v7 a5 g3 ~. \8 D. Z0 a8 Z6 e1 M  F2 [+ z7 I) `
该结构非常大,集总抽象了进程的所有信息,包括进程ID,状态,父进程,子进程,同级,处理器寄存器,打开的文件,地址空间等。系统使用循环双向链接列表进行存储 所有过程描述符。
- {- F4 X$ q* z& I
像这样的大型结构肯定会占用大量内存空间。为每个进程提供较小的内核堆栈大小(可以使用编译时选项进行配置,但默认情况下限制为一页,即对于32位体系结构严格为4KB(一个页),对于64位体系结构严格为8KB(两个页) –内核堆栈不具备增长或收缩),以这种浪费的方式使用资源并不是很方便。因此,决定在堆栈中放置一个更简单的结构,并带有指向实际task_struct的指针,从而引申出thread_info。

  r# Y7 {6 t, u5 B& b7 V0 {4 y
抽象建模思想看进程描述符& p* Z2 Z: n! d: |4 @6 ?: ]

) F3 s$ V' ^1 @1 Q! E- ^; ], Q$ g
  A  j3 Z& {4 G# Q- \
进程首先是操作系统对底层进行抽象而提供面向应用接口的一种抽象,而进程描述符则将底层资源、进程本身的调度从以下几个大的方面进行高级别的抽象封装:
8 O0 Y6 g; i' @1 u1 T; M
  • 应用程序信息抽象
  • 操作系统资源抽象
  • 调度接口抽象
  • 内存管理抽象
  • 账户信息抽象
  • ......
    4 t. Z2 T! D% [/ B4 j1 O0 D/ V
* U* S: x. p' h# _8 c; D
通过预读进程描述符,个人将进程描述相关信息大致分为以下几个大类抽象:
  • 调度相关抽象

    6 e$ l/ O* m/ N1 p+ N
微信图片_20200426175143.png
涉及thread_info、优先级、栈、上下文切换、调度相关链表等关键数据。
  • CPU相关抽象 微信图片_20200426175146.png

    & P9 m8 D& i5 s5 B, H2 j# j
涉及SMP多核处理抽象、CPUSET子系统相关、当前CPU等相关数据抽象。
  • 保护机制抽象
    + L' \$ \/ I$ F6 n4 b' k
微信图片_20200426175149.png
  • 内存管理抽象2 G) g9 q) l, \8 R
微信图片_20200426175153.png
  • 缓存相关抽象9 `7 l7 C4 l9 q3 ~1 ~4 h6 v5 N
微信图片_20200426175156.png
http://blog.csdn.net/wang_xya/article/details/35234429
  • 信号通信抽象
    * A% W1 g9 X& G; [+ l! E
微信图片_20200426175159.png
  • 接口相关抽象" |5 i5 a% d' n3 M3 n  ?* i
微信图片_20200426175203.png

; y* b* I3 Y( j+ |3 ^
  • 调试跟踪抽象2 f$ W0 u& q3 W2 A0 o
微信图片_20200426175206.png
  • 安全机制抽象
      t: i& P8 e9 o5 j
微信图片_20200426175209.png

. D8 u. o. W6 V0 z& r+ {4 j
  • 资源管理抽象
    % L* T) H3 p/ X& z$ K
微信图片_20200426175213.png
  • 杂项信息抽象
    $ o* J6 g' m4 v
微信图片_20200426175216.png
最后附上些整理搜集到数据域的一些较详细的介绍。
thread_info
该字段保存特定于处理器的状态信息,并且是进程描述符的关键元素。具体定义在./arch/xxx/include/asm/thread_info.h中。
  • entry.S需要立即访问此结构的低级任务数据应完全适合一个缓存行,此结构共享主管堆栈页面
  • 如果更改此结构的内容,则还必须更改汇编代码。
  • 因为thread_info包含了当前进程的指针,存储在栈底或栈顶,取决于不同体系架构栈的增长方向,利用thread_info可以快速的访问当前进程的信息,而不必依次遍历。
    3 c2 G0 O$ t* R, G
ARM32的定义:
struct thread_info {
! N) i9 g2 I! D9 z# R unsigned long flags;  /* low level flags */
; R9 d3 C( T0 {( b! F1 U5 a- u- a int       preempt_count; /* 0 => preemptable, <0 => bug */1 @( m2 b0 F" p  ?
mm_segment_t addr_limit; /* address limit */
& ?; |2 ~' v  ^; P) F, m struct task_struct *task;  /* main task structure */  x9 F6 F. j! ^$ H* ~
__u32   cpu;  /* cpu */
+ _; y" W: z0 T% g1 f9 P. I __u32   cpu_domain; /* cpu domain */
( B! l" ^+ s7 L9 ]: |( I. t4 u+ s$ h7 i$ `#ifdef CONFIG_STACKPROTECTOR_PER_TASK: @( {9 ~" F! A7 H( {. {1 d) Z
unsigned long  stack_canary;
/ d! r+ k& v1 l, v#endif5 q& q) M- e0 m: V* X" X1 ^7 |2 F
struct cpu_context_save cpu_context; /* cpu context */% G% S; r0 Q& }9 C
__u32   syscall; /* syscall number */
* H8 E, s3 V; ^. @0 e9 w2 K$ f __u8   used_cp[16]; /* thread used copro */$ k1 A" Z5 N6 ]5 Z7 g
unsigned long  tp_value[2]; /* TLS registers */
# K0 {6 g: a; g# Q4 I" p#ifdef CONFIG_CRUNCH/ r) r. x6 {1 X% y* M: _
struct crunch_state crunchstate;& P, J) u" I9 v' ?
#endif
/ T! M# G) j6 n$ R union fp_state  fpstate __attribute__((aligned(8)));7 o3 X# A# s& U, ]
union vfp_state  vfpstate;9 M" y7 I4 d1 q" ^5 Y' c5 ?
#ifdef CONFIG_ARM_THUMBEE
4 s" [% {6 {* \6 b unsigned long  thumbee_state; /* ThumbEE Handler Base register */. o% x3 k3 [# [2 J2 F7 ?
#endif! \/ z1 |( O8 G) ~* {
};
: V5 i. y% g. v7 T1 _
从书上和网上看到都是前面这样描述的,但是对于ARM64的却没有当前进程指针,这是为何呢?没弄明白,有谁知道告诉下我呗。
struct thread_info {
" f7 W7 v/ C' ?. _' Z- p0 \. Z unsigned long flags;  /* low level flags */$ A4 p3 }3 f% }) P5 P( e
mm_segment_t    addr_limit; /* address limit */
9 Q. j( v( Z" f2 P+ h2 P#ifdef CONFIG_ARM64_SW_TTBR0_PAN& c7 z& {, y$ B0 M/ T9 C7 Z
u64   ttbr0;     /* saved TTBR0_EL1 */
! y3 H# Z' n& u2 c5 }* h# R#endif$ l( D7 y5 ], z" j) y% t4 y
union {% A& W8 a  N  ?7 T( |
  u64  preempt_count;    /* 0 => preemptible, <0 => bug */( {2 ^( S; k2 M4 H7 j0 _
  struct {
+ Z- }/ |: d+ k#ifdef CONFIG_CPU_BIG_ENDIAN
7 ^8 L/ D, f- e% Q- @" _$ P: D% {' H   u32 need_resched;
8 E2 F9 T' \" f1 ^) F$ f   u32 count;
" L% A* K( |7 r- E1 d  v#else$ l" t6 Y* ?' x: G9 g
   u32 count;  G* M/ ]) q, J5 g6 V' L
   u32 need_resched;2 ?. C, p/ M- h8 f
#endif
$ Z0 v/ |! H$ v  } preempt;2 \0 D4 @. Y) s8 {" n
};
4 }1 l' s, ~; J2 w" h};
7 F$ n9 _' B/ k* ?. Z# ]& ?! u
利用如下的几种方式,可以获取thread_info信息:
  • static inline struct thread_info *current_thread_info(void)
  • #define GET_THREAD_INFO(reg)
  • ...8 G6 Q1 u4 V: J' B: C2 n( D0 w: [
SLUB 分配器
thread_info实现了进程存储对描述符的引用以及如何访问它们。但是,如果task_struct不是在内核堆栈内部,则task_struct到底位于内存中的什么位置?为此,Linux提供了一种特殊的内存管理机制,称为SLUB层。SLUB动态生成task_struct,并把thread_info存在栈底或栈顶。
volatile long state
进程状态,可取的进程状态:
  • TASK_RUNNING:  可执行态
  • TASK_INTERRUPTIBLE:可中断
  • TASK_UNINTERRUPTIBLE:不可中断
  • __TASK_STOPPED:停止态
  • __TASK_TRACED:被其他进程跟踪的进程4 ?( d  I5 r: j9 h' `+ e$ E3 j$ s
为何用volatile修饰。由于内核经常需要从不同位置更改进程的状态,例如,如果在单个CPU硬件上同时将两个进程设置为RUNNABLE。熟悉单片机编程的朋友一定知道,当在中断函数中需要修改以及在中断外部也会被修改的变量,就会使用到volatile修饰变量。
randomized_struct_fields_start
这是gcc的一个插件(插件来自于Grsecurity),其作用就是这之后的变量不会按照声明顺序存储在内存中,而会按照一定的随机顺序存放,这样做是基于安全考虑,比如应用程序的进程描述符被劫持,如果按顺序存放,则容易篡改其内容。
赞 收藏 评论0 发布时间:2020-4-26 17:54

举报

0个回答
关于
我们是谁
投资者关系
意法半导体可持续发展举措
创新与技术
意法半导体官网
联系我们
联系ST分支机构
寻找销售人员和分销渠道
社区
媒体中心
活动与培训
隐私策略
隐私策略
Cookies管理
行使您的权利
官方最新发布
人形机器人运动控制、感知与智能配电
半导体创新技术与应用方向
EE架构与软件定义汽车
12V/48V 汽车智能配电(SPD)
区域控制单元(ZCU)与分区架构
关注我们
st-img 微信公众号
st-img 手机版