导航:首页 > 操作系统 > linux用户态锁

linux用户态锁

发布时间:2022-06-28 09:10:40

1. linux 用户进程 可以抢占内核进程吗

1.2.1 调度过程中关闭内核抢占
我们在上一篇linux内核主调度器schele(文章链接, CSDN, Github)中在分析主调度器的时候, 我们会发现内核在进行调度之前都会通过preempt_disable关闭内核抢占, 而在完成调度工作后, 又会重新开启内核抢占
参见主调度器函数schele
do {
preempt_disable(); /* 关闭内核抢占 */
__schele(false); /* 完成调度 */
sched_preempt_enable_no_resched(); /* 开启内核抢占 */

} while (need_resched()); /* 如果该进程被其他进程设置了TIF_NEED_RESCHED标志,则函数重新执行进行调度 */123456123456

这个很容易理解, 我们在内核完成调度器过程中, 这时候如果发生了内核抢占, 我们的调度会被中断, 而调度却还没有完成, 这样会丢失我们调度的信息.
1.2.2 调度完成检查need_resched看是否需要重新调度
而同样我们可以看到, 在调度完成后, 内核会去判断need_resched条件, 如果这个时候为真, 内核会重新进程一次调度.
这个的原因, 我们在前一篇博客中, 也已经说的很明白了,
内核在thread_info的flag中设置了一个标识来标志进程是否需要重新调度, 即重新调度need_resched标识TIF_NEED_RESCHED, 内核在即将返回用户空间时会检查标识TIF_NEED_RESCHED标志进程是否需要重新调度,如果设置了,就会发生调度, 这被称为用户抢占
2 非抢占式和可抢占式内核
为了简化问题,我使用嵌入式实时系统uC/OS作为例子
首先要指出的是,uC/OS只有内核态,没有用户态,这和Linux不一样
多任务系统中, 内核负责管理各个任务, 或者说为每个任务分配CPU时间, 并且负责任务之间的通讯.
内核提供的基本服务是任务切换. 调度(Scheler),英文还有一词叫dispatcher, 也是调度的意思.
这是内核的主要职责之一, 就是要决定该轮到哪个任务运行了. 多数实时内核是基于优先级调度法的, 每个任务根据其重要程度的不同被赋予一定的优先级. 基于优先级的调度法指,CPU总是让处在就绪态的优先级最高的任务先运行. 然而, 究竟何时让高优先级任务掌握CPU的使用权, 有两种不同的情况, 这要看用的是什么类型的内核, 是不可剥夺型的还是可剥夺型内核
2.1 非抢占式内核
非抢占式内核是由任务主动放弃CPU的使用权
非抢占式调度法也称作合作型多任务, 各个任务彼此合作共享一个CPU. 异步事件还是由中断服务来处理. 中断服务可以使一个高优先级的任务由挂起状态变为就绪状态.
但中断服务以后控制权还是回到原来被中断了的那个任务, 直到该任务主动放弃CPU的使用权时,那个高优先级的任务才能获得CPU的使用权。非抢占式内核如下图所示.

非抢占式内核的优点有
中断响应快(与抢占式内核比较);
允许使用不可重入函数;
几乎不需要使用信号量保护共享数据, 运行的任务占有CPU,不必担心被别的任务抢占。这不是绝对的,在打印机的使用上,仍需要满足互斥条件。
非抢占式内核的缺点有
任务响应时间慢。高优先级的任务已经进入就绪态,但还不能运行,要等到当前运行着的任务释放CPU
非抢占式内核的任务级响应时间是不确定的,不知道什么时候最高优先级的任务才能拿到CPU的控制权,完全取决于应用程序什么时候释放CPU
2.2 抢占式内核
使用抢占式内核可以保证系统响应时间. 最高优先级的任务一旦就绪, 总能得到CPU的使用权。当一个运行着的任务使一个比它优先级高的任务进入了就绪态, 当前任务的CPU使用权就会被剥夺,或者说被挂起了,那个高优先级的任务立刻得到了CPU的控制权。如果是中断服务子程序使一个高优先级的任务进入就绪态,中断完成时,中断了的任务被挂起,优先级高的那个任务开始运行。
抢占式内核如下图所示

抢占式内核的优点有
使用抢占式内核,最高优先级的任务什么时候可以执行,可以得到CPU的使用权是可知的。使用抢占式内核使得任务级响应时间得以最优化。
抢占式内核的缺点有:
不能直接使用不可重入型函数。调用不可重入函数时,要满足互斥条件,这点可以使用互斥型信号量来实现。如果调用不可重入型函数时,低优先级的任务CPU的使用权被高优先级任务剥夺,不可重入型函数中的数据有可能被破坏。
3 linux用户抢占
3.1 linux用户抢占
当内核即将返回用户空间时, 内核会检查need_resched是否设置, 如果设置, 则调用schele(),此时,发生用户抢占.
3.2 need_resched标识
内核如何检查一个进程是否需要被调度呢?
内核在即将返回用户空间时检查进程是否需要重新调度,如果设置了,就会发生调度, 这被称为用户抢占, 因此内核在thread_info的flag中设置了一个标识来标志进程是否需要重新调度, 即重新调度need_resched标识TIF_NEED_RESCHED
并提供了一些设置可检测的函数

函数
描述
定义

set_tsk_need_resched 设置指定进程中的need_resched标志 include/linux/sched.h, L2920
clear_tsk_need_resched 清除指定进程中的need_resched标志 include/linux/sched.h, L2926
test_tsk_need_resched 检查指定进程need_resched标志 include/linux/sched.h, L2931
而我们内核中调度时常用的need_resched()函数检查进程是否需要被重新调度其实就是通过test_tsk_need_resched实现的, 其定义如下所示
// http://lxr.free-electrons.com/source/include/linux/sched.h?v=4.6#L3093
static __always_inline bool need_resched(void)
{
return unlikely(tif_need_resched());
}

// http://lxr.free-electrons.com/source/include/linux/thread_info.h?v=4.6#L106
#define tif_need_resched() test_thread_flag(TIF_NEED_RESCHED)1234567812345678

3.3 用户抢占的发生时机(什么时候需要重新调度need_resched)
一般来说,用户抢占发生几下情况:
从系统调用返回用户空间;
从中断(异常)处理程序返回用户空间
从这里我们可以看到, 用户抢占是发生在用户空间的抢占现象.
更详细的触发条件如下所示, 其实不外乎就是前面所说的两种情况: 从系统调用或者中断返回用户空间
时钟中断处理例程检查当前任务的时间片,当任务的时间片消耗完时,scheler_tick()函数就会设置need_resched标志;
信号量、等到队列、completion等机制唤醒时都是基于waitqueue的,而waitqueue的唤醒函数为default_wake_function,其调用try_to_wake_up将被唤醒的任务更改为就绪状态并设置need_resched标志。
设置用户进程的nice值时,可能会使高优先级的任务进入就绪状态;
改变任务的优先级时,可能会使高优先级的任务进入就绪状态;
新建一个任务时,可能会使高优先级的任务进入就绪状态;
对CPU(SMP)进行负载均衡时,当前任务可能需要放到另外一个CPU上运行
4 linux内核抢占
4.1 内核抢占的概念
对比用户抢占, 顾名思义, 内核抢占就是指一个在内核态运行的进程, 可能在执行内核函数期间被另一个进程取代.
4.2 为什么linux需要内核抢占
linux系统中, 进程在系统调用后返回用户态之前, 或者是内核中某些特定的点上, 都会调用调度器. 这确保除了一些明确指定的情况之外, 内核是无法中断的, 这不同于用户进程.
如果内核处于相对耗时的操作中, 比如文件系统或者内存管理相关的任务, 这种行为可能会带来问题. 这种情况下, 内核代替特定的进程执行相当长的时间, 而其他进程无法执行, 无法调度, 这就造成了系统的延迟增加, 用户体验到”缓慢”的响应. 比如如果多媒体应用长时间无法得到CPU, 则可能发生视频和音频漏失现象.
编译内核时如果启用了对内核抢占的支持, 则可以解决这些问题. 如果高优先级进程有事情需要完成, 那么在启用了内核抢占的情况下, 不仅用户空间应用程序可以被中断, 内核也可以被中断,
linux内核抢占是在Linux2.5.4版本发布时加入的, 尽管使内核可抢占需要的改动特别少, 但是该机制不像抢占用户空间进程那样容易实现. 如果内核无法一次性完成某些操作(例如, 对数据结构的操作), 那么可能出现静态条件而使得系统不一致.
内核抢占和用户层进程被其他进程抢占是两个不同的概念, 内核抢占主要是从实时系统中引入的, 在非实时系统中的确也能提高系统的响应速度, 但也不是在所有情况下都是最优的,因为抢占也需要调度和同步开销,在某些情况下甚至要关闭内核抢占, 比如前面我们将主调度器的时候, linux内核在完成调度的过程中是关闭了内核抢占的.
内核不能再任意点被中断, 幸运的是, 大多数不能中断的点已经被SMP实现标识出来了. 并且在实现内核抢占时可以重用这些信息. 如果内核可以被抢占, 那么单处理器系统也会像是一个SMP系统
4.3 内核抢占的发生时机
要满足什么条件,kernel才可以抢占一个任务的内核态呢?
没持有锁。锁是用于保护临界区的,不能被抢占。
Kernel code可重入(reentrant)。因为kernel是SMP-safe的,所以满足可重入性。
内核抢占发生的时机,一般发生在:
当从中断处理程序正在执行,且返回内核空间之前。当一个中断处理例程退出,在返回到内核态时(kernel-space)。这是隐式的调用schele()函数,当前任务没有主动放弃CPU使用权,而是被剥夺了CPU使用权。
当内核代码再一次具有可抢占性的时候,如解锁(spin_unlock_bh)及使能软中断(local_bh_enable)等, 此时当kernel code从不可抢占状态变为可抢占状态时(preemptible again)。也就是preempt_count从正整数变为0时。这也是隐式的调用schele()函数
如果内核中的任务显式的调用schele(), 任务主动放弃CPU使用权
如果内核中的任务阻塞(这同样也会导致调用schele()), 导致需要调用schele()函数。任务主动放弃CPU使用权
内核抢占,并不是在任何一个地方都可以发生,以下情况不能发生
内核正进行中断处理。在Linux内核中进程不能抢占中断(中断只能被其他中断中止、抢占,进程不能中止、抢占中断),在中断例程中不允许进行进程调度。进程调度函数schele()会对此作出判断,如果是在中断中调用,会打印出错信息。
内核正在进行中断上下文的Bottom Half(中断下半部,即软中断)处理。硬件中断返回前会执行软中断,此时仍然处于中断上下文中。如果此时正在执行其它软中断,则不再执行该软中断。
内核的代码段正持有spinlock自旋锁、writelock/readlock读写锁等锁,处干这些锁的保护状态中。内核中的这些锁是为了在SMP系统中短时间内保证不同CPU上运行的进程并发执行的正确性。当持有这些锁时,内核不应该被抢占。
内核正在执行调度程序Scheler。抢占的原因就是为了进行新的调度,没有理由将调度程序抢占掉再运行调度程序。
内核正在对每个CPU“私有”的数据结构操作(Per-CPU date structures)。在SMP中,对于per-CPU数据结构未用spinlocks保护,因为这些数据结构隐含地被保护了(不同的CPU有不一样的per-CPU数据,其他CPU上运行的进程不会用到另一个CPU的per-CPU数据)。但是如果允许抢占,但一个进程被抢占后重新调度,有可能调度到其他的CPU上去,这时定义的Per-CPU变量就会有问题,这时应禁抢占。

2. linux内核态和linux用户态上常见的临界区保护手段有哪些,他们适合在哪些场景下使用

大部分都在用spin lock自旋锁。而且他也很通用。不过小语句,类似以i++之类还是用原子操作比较好点。

3. 请教linux下用户态进程调度问题

在进行Linux系统操作的时候,有时候会遇到一次用户态进程死循环,即系统反应迟钝、进程挂死等问题,那么遇到这些问题又该如何解决呢?下面小编就给大家介绍下一次用户态进程死循环的问题该如何处理。
Linux下如何处理一次用户态进程死循环问题
1、问题现象
业务进程(用户态多线程程序)挂死,操作系统反应迟钝,系统日志没有任何异常。从进程的内核态堆栈看,看似所有线程都卡在了内核态的如下堆栈流程中:
[root@vmc116 ~]# cat /proc/27007/task/11825/stack
[《ffffffff8100baf6》] retint_careful+0x14/0x32
[《ffffffffffffffff》] 0xffffffffffffffff
2、问题分析
1)内核堆栈分析
从内核堆栈看,所有进程都阻塞在 retint_careful上,这个是中断返回过程中的流程,代码(汇编)如下:
entry_64.S
代码如下:
ret_from_intr:
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
decl PER_CPU_VAR(irq_count)
/* Restore saved previous stack */
popq %rsi
CFI_DEF_CFA rsi,SS+8-RBP /* reg/off reset after def_cfa_expr */
leaq ARGOFFSET-RBP(%rsi), %rsp
CFI_DEF_CFA_REGISTER rsp
CFI_ADJUST_CFA_OFFSET RBP-ARGOFFSET
。。。
retint_careful:
CFI_RESTORE_STATE
bt $TIF_NEED_RESCHED,%edx
jnc retint_signal
TRACE_IRQS_ON
ENABLE_INTERRUPTS(CLBR_NONE)
pushq_cfi %rdi
SCHEDULE_USER
popq_cfi %rdi
GET_THREAD_INFO(%rcx)
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
jmp retint_check
这其实是用户态进程在用户态被中断打断后,从中断返回的流程,结合retint_careful+0x14/0x32,进行反汇编,可以确认阻塞的点其实就在
SCHEDULE_USER
这其实就是调用schele()进行调度,也就是说当进程走到中断返回的流程中时,发现需要调度(设置了TIF_NEED_RESCHED),于是在这里发生了调度。
有一个疑问:为什么在堆栈中看不到schele()这一级的栈帧呢?
因为这里是汇编直接调用的,没有进行相关栈帧压栈和上下文保存操作。
2)进行状态信息分析
从top命令结果看,相关线程实际一直处于R状态,CPU几乎完全耗尽,而且绝大部分都消耗在用户态:
[root@vmc116 ~]# top
top - 09:42:23 up 16 days, 2:21, 23 users, load average: 84.08, 84.30, 83.62
Tasks: 1037 total, 85 running, 952 sleeping, 0 stopped, 0 zombie
Cpu(s): 97.6%us, 2.2%sy, 0.2%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 32878852k total, 32315464k used, 563388k free, 374152k buffers
Swap: 35110904k total, 38644k used, 35072260k free, 28852536k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27074 root 20 0 5316m 163m 14m R 10.2 0.5 321:06.17 z_itask_templat
27084 root 20 0 5316m 163m 14m R 10.2 0.5 296:23.37 z_itask_templat
27085 root 20 0 5316m 163m 14m R 10.2 0.5 337:57.26 z_itask_templat
27095 root 20 0 5316m 163m 14m R 10.2 0.5 327:31.93 z_itask_templat
27102 root 20 0 5316m 163m 14m R 10.2 0.5 306:49.44 z_itask_templat
27113 root 20 0 5316m 163m 14m R 10.2 0.5 310:47.41 z_itask_templat
25730 root 20 0 5316m 163m 14m R 10.2 0.5 283:03.37 z_itask_templat
30069 root 20 0 5316m 163m 14m R 10.2 0.5 283:49.67 z_itask_templat
13938 root 20 0 5316m 163m 14m R 10.2 0.5 261:24.46 z_itask_templat
16326 root 20 0 5316m 163m 14m R 10.2 0.5 150:24.53 z_itask_templat
6795 root 20 0 5316m 163m 14m R 10.2 0.5 100:26.77 z_itask_templat
27063 root 20 0 5316m 163m 14m R 9.9 0.5 337:18.77 z_itask_templat
27065 root 20 0 5316m 163m 14m R 9.9 0.5 314:24.17 z_itask_templat
27068 root 20 0 5316m 163m 14m R 9.9 0.5 336:32.78 z_itask_templat
27069 root 20 0 5316m 163m 14m R 9.9 0.5 338:55.08 z_itask_templat
27072 root 20 0 5316m 163m 14m R 9.9 0.5 306:46.08 z_itask_templat
27075 root 20 0 5316m 163m 14m R 9.9 0.5 316:49.51 z_itask_templat
。。。
3)进程调度信息
从相关线程的调度信息看:
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15681811525768 129628804592612 3557465
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15682016493013 129630684625241 3557509
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15682843570331 129638127548315 3557686
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15683323640217 129642447477861 3557793
[root@vmc116 ~]# cat /proc/27007/task/11825/schedstat
15683698477621 129645817640726 3557875
发现相关线程的调度统计一直在增加,说明相关线程一直是在被调度运行的,结合其状态也一直是R,推测很可能在用户态发生了死循环(或者非睡眠死锁)。
这里又有问题:为什么从top看每个线程的CPU占用率只有10%左右,而不是通常看到的死循环进程导致的100%的占用率?
因为线程数很多,而且优先级都一样,根据CFS调度算法,会平均分配时间片,不会让其中一个线程独占CPU。结果为多个线程间轮流调度,消耗掉了所有的cpu。。
另一个问题:为什么这种情况下,内核没有检测到softlockup?
因为业务进程的优先级不高,不会影响watchdog内核线程(最高优先级的实时线程)的调度,所以不会产生softlockup的情况。
再一个问题:为什么每次查看线程堆栈时,总是阻塞在retint_careful,而不是其它地方?
因为这里(中断返回的时候)正是调度的时机点,在其它时间点不能发生调度(不考虑其它情况~),而我们查看线程堆栈的行为,也必须依赖于进程调度,所以我们每次查看堆栈时,正是查看堆栈的进程(cat命令)得到调度的时候,这时正是中断返回的时候,所以正好看到的阻塞点为retint_careful。
4)用户态分析
从上面的分析看,推测应该是用户态发生了死锁。
用户态确认方法:
部署debug信息,然后gdb attach相关进程,确认堆栈,并结合代码逻辑分析。
最终确认该问题确为用户态进程中产生了死循环。

4. linux 文件锁,系统调用和库函数之间的关系

系统调用:是操作系统为用户态运行的进程和硬件设备(如CPU、磁盘、打印机等)进行交互提供的一组接口,即就是设置在应用程序和硬件设备之间的一个接口层。可以说是操作系统留给用户程序的一个接口。再来说一下,linux内核是单内核,结构紧凑,执行速度快,各个模块之间是直接调用的关系。放眼望整个linux系统,从上到下依次是用户进程->linux内核->硬件。其中系统调用接口是位于Linux内核中的,如果再稍微细分一下的话,整个linux系统从上到下可以是:用户进程->系统调用接口->linux内核子系统->硬件,也就是说Linux内核包括了系统调用接口和内核子系统两部分;或者从下到上可以是:物理硬件->OS内核->OS服务->应用程序,其中操作系统起到“承上启下”的关键作用,向下管理物理硬件,向上为操作系服务和应用程序提供接口,这里的接口就是系统调用了。 一般地,操作系统为了考虑实现的难度和管理的方便,它只提供一少部分的系统调用,这些系统调用一般都是由C和汇编混合编写实现的,其接口用C来定义,而具体的实现则是汇编,这样的好处就是执行效率高,而且,极大的方便了上层调用。

库函数:顾名思义是把函数放到库里。是把一些常用到的函数编完放到一个文件里,供别人用。别人用的时候把它所在的文件名用#include<>加到里面就可以了。一般是放到lib文件里的。一般是指编译器提供的可在c源程序中调用的函数。可分为两类,一类是c语言标准规定的库函数,一类是编译器特定的库函数。(由于版权原因,库函数的源代码一般是不可见的,但在头文件中你可以看到它对外的接口)

5. 自旋锁 是用于线程同步还是linux内核同步

自旋锁在线程同步和linux内核同步中都有,但在用户态使用的比较少,在内核使用的比较多

6. linux中程序处于停止态可以被唤醒吗

在Linux中,休眠主要分三个主要的步骤:
1) 冻结用户态进程和内核态任务
2) 调用注册的设备的suspend的回调函数, 顺序是按照注册顺序
3) 休眠核心设备和使CPU进入休眠态, 冻结进程是内核把进程列表中所有的进程的状态都设置为停止,并且保存下所有进程的上下文.
当这些进程被解冻的时候,他们是不知道自己被冻结过的,只是简单的继续执行。
如何让Linux进入休眠呢?用户可以通过读写sys文件/sys /power/state 是实现控制系统进入休眠. 比如
# echo mem > /sys/power/state
命令系统进入休眠. 也可以使用

# cat /sys/power/state
来得到内核支持哪几种休眠方式.
1. 相关代码

• kernel/kernel/power/main.c
• kernel/arch/arm/mach-xxx/pm.c
• kernel/driver/base/power/main.c

接下来让我们详细的看一下Linux是怎么休眠/唤醒的:
用户对于/sys/power/state 的读写会调用到 kernel/kernel/power/main.c中的state_store(),
用户可以写入 const char * const pm_states[] 中定义的字符串, 比如"mem", "standby"。

const char *const pm_states[PM_SUSPEND_MAX] = {
#ifdef CONFIG_EARLYSUSPEND
[PM_SUSPEND_ON] = "on",
#endif
[PM_SUSPEND_STANDBY] = "standby",
[PM_SUSPEND_MEM] = "mem",
};
常见有standby(suspend to RAM)、mem(suspend to RAM)和disk(suspend to disk),只是standby耗电更多,返回到正常工作状态的时间更短。

然后state_store()会调用enter_state()<注:这是经典Linux调用流程, 在Android系统中,
Kernel将调用request_suspend_state,而不是enter_state>,它首先会检查一些状态参数,然后同步文件系统。

2. 准备, 冻结进程
当进入到suspend_prepare()中以后, 它会给suspend分配一个虚拟终端来输出信息, 然后广播一个系统要进入suspend的Notify,
关闭掉用户态的helper进程, 然后一次调用suspend_freeze_processes()冻结所有的进程, 这里会保存所有进程当前的状态,
也许有一些进程会拒绝进入冻结状态, 当有这样的进程存在的时候, 会导致冻结失败,此函数就会放弃冻结进程,并且解冻刚才冻结的所有进程。

3. 让外设进入休眠
现在, 所有的进程(也包括workqueue/kthread) 都已经停止了,内核态人物有可能在停止的时候握有一些信号量,
所以如果这时候在外设里面去解锁这个信号量有可能会发生死锁,所以在外设的suspend()函数里面作lock/unlock锁要非常小心,
这里建议设计的时候就不要在suspend()里面等待锁。而且因为suspend的时候,有一些Log是无法输出的,所以一旦出现问题,非常难调试。

然后kernel在这里会尝试释放一些内存。

最后会调用suspend_devices_and_enter()来把所有的外设休眠, 在这个函数中,
如果平台注册了suspend_ops(通常是在板级定义中定义和注册,在kernel/arch/arm/mach-xx/pm.c中调用suspend_set_ops),
这里就会调用 suspend_ops->begin(); 然后调用dpm_suspend_start,他们会依次调用驱动的suspend() 回调来休眠掉所有的设备。

当所有的设备休眠以后, suspend_ops->prepare()会被调用, 这个函数通常会作一些准备工作来让板机进入休眠。
接下来Linux,在多核的CPU中的非启动CPU会被关掉,通过注释看到是避免这些其他的CPU造成race condio,接下来的以后只有一个CPU在运行了。

suspend_ops 是板级的电源管理操作, 通常注册在文件 arch/arch/mach-xxx/pm.c 中.

接下来, suspend_enter()会被调用, 这个函数会关闭arch irq, 调用 device_power_down(), 它会调用suspend_late()函数,
这个函数是系统真正进入休眠最后调用的函数,通常会在这个函数中作最后的检查。 如果检查没问题, 接下来休眠所有的系统设备和总线,
并且调用 suspend_pos->enter() 来使CPU进入省电状态,这时就已经休眠了。代码的执行也就停在这里了。

三、Linux Resume流程

如果在休眠中系统被中断或者其他事件唤醒,接下来的代码就会开始执行,这个唤醒的顺序是和休眠的循序相反的,
所以系统设备和总线会首先唤醒,使能系统中断,使能休眠时候停止掉的非启动CPU, 以及调用suspend_ops->finish(),
而且在suspend_devices_and_enter()函数中也会继续唤醒每个设备,使能虚拟终端, 最后调用 suspend_ops->end()。

在返回到enter_state()函数中的,当 suspend_devices_and_enter() 返回以后,外设已经唤醒了,
但是进程和任务都还是冻结状态, 这里会调用suspend_finish()来解冻这些进程和任务, 而且发出Notify来表示系统已经从suspend状态退出, 唤醒终端。

到这里,所有的休眠和唤醒就已经完毕了,系统继续运行了。

7. 求助:linux 用户态 线程同步中信号量,互斥

你好,
1.信号量和自旋锁一般都用于互斥.
2.信号量一般进行上下文切换,可休眠,但不可中断.
3.自旋锁可中断(中断临界区无获锁操作),不可休眠.
4.信号量互斥,一般临界区TIME(sem)较长; 自旋锁,一般临界区TIME(lock)较短.

8. linux pthread 信号量 占用资源吗

glibc提供的pthread互斥信号量可以用在进程内部,也可以用在进程间,可以在初始化时通过pthread_mutexattr_setpshared接口设置该信号量属性,表示是进程内还是进程间。进程内的使用较为简单,本文的总结主要是针对进程间的,进程内的也可以参考,其代码实现原理是类似的。
一、实现原理
pthread mutex的实现是非常轻量级的,采用原子操作+futex系统调用。
在没有竞争的情况下,即锁空闲时,任务获取信号量只需要通过原子操作锁的状态值,把值置为占有,再记录其他一些俄信息(owner,计数,如果使能回收功能则串入任务的信号量回收链表等),然后就返回了。
如果在获取锁时发现被占用了,如果调用者需要睡眠等待,这时候会触发futex系统调用,由内核继续处理,内核会让调用任务睡眠,并在适当时候唤醒(超时或者锁状态为可用)。
占用锁的任务释放锁时,如果没有任务等待这把锁,只需要把锁状态置为空闲即可。如果发现有其他任务在等待此锁,则触发futex系统调用,由内核唤醒等待任务。
由此可见,在没有竞争的情况下,mutex只需要在用户态操作锁状态值,无须陷入内核,是非常高效的。
获取到锁的任务没有陷入内核,那么当锁支持优先级翻转时,高优先级任务等待这把锁,正常处理必须提升占用锁的任务优先级。内核又是怎么知道是哪个任务占用了锁呢?实现上,复用了锁的状态值,该值在空闲态时为0,非空闲态则保存了锁的持有者ID,即PID,内核态通过PID就知道是那个任务了。
二、内核对锁的管理
内核维护了一个hash链表,每把锁都被插入到hash链表中去,hash值的计算如下(参考get_futex_key):1,如果是进程内的锁,则通
过锁的虚拟地址+任务mm指针值+锁在页内偏移;2,如果是进程间的锁,则会获取锁虚拟地址对应物理地址的page描述符,由page描述符构造
hash值。
这样计算的原因是进程间的锁在各个进程内虚拟地址可能是不同的,但都映射到同一个物理地址,对应同一个page描述符。所以,内
核使用它来定位是否同一个锁。
这里对进程间互斥锁计算hash值的方法,给进程间共享锁的使用设置了一个隐患条件。下面描述这个问题。

三、进程间互斥信号量的使用限制:必须在系统管理的内存上定义mutex结构,而不能在用户reserved的共享内存上定义mutex结构。
锁要实现进程间互斥,必须各个进程都能看到这个锁,因此,锁结构必须放在共享内存上。
获取系统的共享内存通过System V的API接口创建:shmget, shmat,shmdt。但是shmget的参数需要一个id值,各进程映射同一块共享内存需要同样的ID值。如果各个进程需要共享的共享内存比较多,如几千上万个,ID值如果管理?shmget的man帮助和一些示例代码给出的是通过ftok函数把一个文件转为ID值(实际就是把文件对应的INODE转为ID值),但实际应用中,如果需要的共享内存个数较多,难道创建成千上万个文件来使用?而且怎么保证文件在进程的生命周期内不会被删除或者重建?
当时开发的系统还存在另外一种共享内存,就是我们通过remap_pfn_range实现的,自己管理了这块内存的申请释放。申请接口参数为字符串,相同的字符串表示同一块内存。因此,倾向于使用自己管理的共享内存存放mutex结构。但在使用中,发现这种方法达不到互斥的效果。为什么?
原因是自己管理的共享内存在内核是通过remap_pfn_range实现的,内核会把这块内存置为reserved,表示非内核管理,获取锁的HASH值时,查找不到page结构,返回失败了。最后的解决方法还是通过shmget申请共享内存,但不是通过ftok获取ID,而是通过字符串转为ID值并处理冲突。

四、进程间互斥信号量回收问题。
假设进程P1获取了进程间信号量,异常退出了,还没有释放信号量,这时候其他进程想来获取信号量,能获取的到吗?
或者进程P1获取了信号量后,其他进程获取不到进入了睡眠后,P1异常退出了,谁来负责唤醒睡眠的进程?
好在系统设计上已经考虑了这一点。
只要在信号量初始化时调用pthread_mutexattr_setrobust_np设置支持信号量回收机制,然后,在获取信号量时,如果原来占有信号量的进程退出了,系统将会返回EOWNERDEAD,判断是这个返回值后,调用pthread_mutex_consistent_np完成信号量owner的切换工作即可。
其原理如下:
任务创建时,会注册一个robust list(用户态链表)到内核的任务控制块TCB中期,获取了信号量时,会把信号量挂入链表。进程复位时,内核会遍历此链表(内核必须非常小心,因为此时的链表信息可能不可靠了,可不能影响到内核),置上ownerdead的标志到锁状态,并唤醒等待在此信号量链表上的进程。
五、pthread接口使用说明
pthread_mutex_init: 根据指定的属性初始化一个mutex,状态为空闲。
pthread_mutex_destroy: 删除一个mutex
pthread_mutex_lock/trylock/timedlock/unlock: 获取锁、释放锁。没有竞争关系的情况下在用户态只需要置下锁的状态值即返回了,无须陷入内核。但是timedlock的入参为超时时间,一般需要调用系统API获取,会导致陷入内核,性能较差,实现上,可先trylock,失败了再timedlock。
pthread_mutexattr_init:配置初始化
pthread_mutexattr_destroy:删除配置初始化接口申请的资源
pthread_mutexattr_setpshared:设置mutex是否进程间共享
pthread_mutexattr_settype:设置类型,如递归调用,错误检测等。
pthread_mutexattr_setprotocol:设置是否支持优先级翻转
pthread_mutexattr_setprioceiling:设置获取信号量的任务运行在最高优先级。
每个set接口都有对应的get接口。

六、pthread结构变量说明

struct __pthread_mutex_s
{
int __lock; ----31bit:这个锁是否有等待者;30bit:这个锁的owner是否已经挂掉了。其他bit位:0锁状态空闲,非0为持有锁的任务PID;
unsigned int __count; ----获取锁的次数,支持嵌套调用,每次获取到锁值加1,释放减1。
int __owner; ----锁的owner
unsigned int __nusers; ----使用锁的任务个数,通常为1(被占用)或0(空闲)
int __kind;----锁的属性,如递归调用,优先级翻转等。
int __spins; ----SMP下,尝试获取锁的次数,尽量不进入内核。
__pthread_list_t __list; ----把锁插入回收链表,如果支持回收功能,每次获取锁时要插入任务控制块的回收链表。
}__data;

9. linux中哪些无关账号需要锁定

linux中需要锁定账号的情况为:

用户在指定时间内输入错误密码的次数达到了相应的次数,账户锁定策略就会将该用户禁用。

linux对账户的锁定功能比windows的要更加广泛,强大,windows组策略中的限制,只是在系统层面的限制。

而linux借助pam(Pluggable Authentication Moles,插件式认证模块)的强大,不单止可以系统层面实现,还能在各中支持pam的应用中实现这种安全锁定策略。

linux中PAM通过提供一些动态链接库和一套统一的API,将系统提供的服务和该服务的认证方式分开,使得系统管理员可以灵活地根据需要给不同的服务配置不同的认证方式而无需更改服务程序,同时也便于向系统中添加新的认证手段。

PAM最初是集成在Solaris中,目前已移植到其它系统中,如Linux、SunOS、HP-UX9.0等。

PAM的配置是通过单个配置文件/etc/pam.conf。RedHat还支持另外一种配置方式,即通过配置目录/etc/pam.d/,且这种的优先级要高于单个配置文件的方式。

(9)linux用户态锁扩展阅读:

在 Linux 中锁定、解锁和检查给定用户帐户的状态的操作:

找到同时有“password”和“pam_unix.so”字段并且附加有“remember=5”的那行,它表示禁止使用最近用过的5个密码(己使用过的密码会被保存在/etc/security/opasswd下面)。

找到同时有“password”和“pam_cracklib.so”字段并且附加有“minlen=10”的那行,它表示最小密码长度为(10-类型数量)。这里的“类型数量”表示不同的字符类型数量。PAM提供4种类型符号作为密码(大写字母、小写字母、数字和标点符号)。

如果密码同时用上了这4种类型的符号,并且你的minlen设为10,那么最短的密码长度允许是6个字符。

使用配置目录/etc/pam.d/,该目录下的每个文件的名字对应服务名,例如ftp服务对应文件/etc/pam.d/ftp。

如果名为xxxx的服务所对应的配置文件/etc/pam.d/xxxx不存 在,则该服务将使用默认的配置文件/etc/pam.d/other。每个文件由如下格式的文本行所构成:

mole-typecontrol-flagmole-patharguments;每个字段的含义和/etc/pam.conf中的相同。

密码复杂度通过/etc/pam.d/system-auth这个文件来实现的。

阅读全文

与linux用户态锁相关的资料

热点内容
国产系统怎么解压 浏览:552
战双程序员 浏览:483
him触摸编程软件 浏览:931
植物大战僵尸存档怎么转移安卓 浏览:852
java栈的元素 浏览:737
程序员与篮球事件 浏览:675
app反编译不完整 浏览:788
电脑上的文件夹怎么调整 浏览:7
服务器无响应是什么原因呀 浏览:984
wd文档里的app怎么制作 浏览:513
电脑里的文件夹没有了一般能恢复吗 浏览:418
哪里有配加密钥匙的 浏览:210
服务器开不了机怎么把数据弄出来 浏览:958
gif动态图片怎么压缩 浏览:521
黑猴子棒球压缩文件解压密码 浏览:631
如何让app适应不同的手机屏幕大小 浏览:10
苹果手机如何给安卓手机分享软件 浏览:761
苹果电脑怎么运行腾讯云服务器 浏览:59
明日之后沙石堡命令助手 浏览:261
蛋糕店用什么样的app 浏览:877