2.2 中度睡眠 进程描述符的state使用TASK_KILLABLE表示这种状态。 可以被致命信号所打断。...为不可中断的睡眠状态，不能被任何信号所唤醒(特定条件没有满足发生信号唤醒可能导致数据不一致等问题，这种场景使用这种睡眠状态，如等待IO读写完成)。 3....如延迟睡眠场景，内核将即将睡眠的任务记录在定时器相关的数据结构中；可睡眠的信号量场景中，内核将即将睡眠的任务加入到信号量的相关链表中。...将即将睡眠的任务从cpu的运行队列中“删除”意义重大：主调度器再次选择下一个任务的时候不会在选择睡眠的任务（因为主调度器总是在运行队列中选择任务运行，除非任务被唤醒，重新加入运行队列）。...当任务睡眠完成，定时器超时，会调用之前在__hrtimer_init_sleeper设置的超时回调函数hrtimer_wakeup将睡眠的任务唤醒（关于进程唤醒在这里就不在赘述，在后面的进程唤醒专题文章在进行详细解读
注：由于篇幅问题，文章分为上下两篇，且这里不区分进程和任务，统一使用任务来表示进程。 主要讲解以下内容： 睡眠的三种状态 睡眠的内核原理 用户态睡眠 内核态睡眠 总结 2....2.2 中度睡眠 进程描述符的state使用TASK_KILLABLE表示这种状态。 可以被致命信号所打断。...为不可中断的睡眠状态，不能被任何信号所唤醒(特定条件没有满足发生信号唤醒可能导致数据不一致等问题，这种场景使用这种睡眠状态，如等待IO读写完成)。 3....如延迟睡眠场景，内核将即将睡眠的任务记录在定时器相关的数据结构中；可睡眠的信号量场景中，内核将即将睡眠的任务加入到信号量的相关链表中。...将即将睡眠的任务从cpu的运行队列中“删除”意义重大：主调度器再次选择下一个任务的时候不会在选择睡眠的任务（因为主调度器总是在运行队列中选择任务运行，除非任务被唤醒，重新加入运行队列）。
，符合我们一般的认识，因为它在计时器使用的过程中通过 local_intr_save 关闭了中断，且利用了 timer_init 定时器函数，去记录指定的时间（传入的参数time），且在这个过程中，将进程的状态设置为睡眠...如果大于 0，这表示当前有睡眠在该条件变量上的进程，因此需要唤醒等待在cv.sem上睡眠的进程。而由于只允许一个进程在管程中执行，所以一旦进程 B 唤醒了别人（进程A），那么自己就需要睡眠。...，如果没有则不需要进行任何操作； 如果由正在等待的进程，则将其中的一个唤醒，这里的等待队列是使用了一个信号量来进行实现的，由于信号量中已经包括了对等待队列的操作，因此要进行唤醒只需要对信号量执行 up...根据前一个问题得知所有 next 信号量上的等待进程一定会被唤醒，那么最后一个被唤醒的 next 进程就会将锁释放掉； 接下来，当前进程被从 next 信号量上被唤醒的时候，首先将 next count...，如果满足，将其从等待中唤醒（使用 cond_signal）； 释放锁，离开管程； 由于限制了管程中在访问共享变量的时候处于 RUNNABLE 的进程只有一个，因此对进程的访问是互斥的；并且由于每个哲学家只可能占有所有需要的资源
布朗大学(Brown University)的一个研究小组已经使用脑机接口技术从非人类灵长类动物大脑中记录了神经信号，并重建了英语单词。...然后信号转移到次级听觉皮层，在那里进一步处理。例如，当人们在听口语时，声音就是通过音素(phonemes)来分类的——音素是使我们能够区分单词的最简单的特征。...从那里，神经数据可以被转换为(可以理解为被翻译为，为什么可以理解为被翻译为，我们可以将识别特定单词相关的神经记录数据作为一种语言，语言是一种信息载体。...对于语言，有人熟悉，也有人不熟悉，熟悉这门语言的人可以将语言所承载的信息翻译给不熟悉这门语言的人听)计算机生成的语音。最后，研究小组用多个指标来评估重建的语音与猕猴听到的原始语音的匹配程度。...研究者比较了解码算法在重构各种音频方面以及使用6种不同的性能指标生成可理解的音频方面的有效性。所有指标中，性能最高的算法是LSTM RNN(红色星号)，下图所示。
可中断的睡眠状态的进程会睡眠直到某个条件变为真，比如说产生一个硬件中断、释放 进程正在等待的系统资源或是传递一个信号都可以是唤醒进程的条件。...不可中断睡眠状态与可中断睡眠状态类似，但是它有一个例外，那就是把信号传递到这种睡眠 状态的进程不能改变它的状态，也就是说它不响应信号的唤醒。...我们可以使用下面的这个函数将刚才那个进入睡眠的进程唤醒。...A 进程的状态仍然是 TASK_RUNNING，所以 wake_up_process() 将 A 进程状态从睡眠状态转变为运行状态的努力 没有起到预期的作用。...4 Linux 内核的例子 在 Linux 操作系统中，内核的稳定性至关重要，为了避免在 Linux 操作系统内核中出现无效唤醒问题， Linux 内核在需要进程睡眠的时候应该使用类似如下的操作： /*
可中断的睡眠状态的进程会睡眠直到某个条件变为真, 比如说产生一个硬件中断、释放进程正在等待的系统资源或是传递一个信号都可以是唤醒进程的条件....不可中断睡眠状态与可中断睡眠状态类似, 但是它有一个例外, 那就是把信号传递到这种睡眠 状态的进程不能改变它的状态, 也就是说它不响应信号的唤醒....请注意该过程不涉及核心调度器. 3.1 wake_up_process 我们可以使用wake_up_process将刚才那个进入睡眠的进程唤醒, 该函数定义在kernel/sched/core.c, line..., 就可以使用wake_up_new_task将进程唤醒并添加到就绪队列中等待调度....TASK_RUNNING，所以wake_up_process将A进程状态从睡眠状态转变为运行状态的努力没有起到预期的作用. 4.3 避免无效抢占 要解决这个问题, 必须使用一种保障机制使得判断链表为空和设置进程状态为睡眠状态成为一个不可分割的步骤才行
深度睡眠与浅度睡眠 众所周知，Linux的进程睡眠有两种常规状态： TASK_INTERRUPTIBLE（浅度睡眠）：可以被等待的资源唤醒，也能被signal唤醒； TASK_UNINTERRUPTIBLE...浅度睡眠的进程，则可以被信号唤醒，对于常规的键盘、串口、触摸屏等等这些I/O设备，显然符合此类模型。...可杀的深度睡眠 Linux因此推出了一个特殊的深度睡眠状态，叫做 TASK_KILLABLE（可杀的深度睡眠）：可以被等到的资源唤醒，不能被常规信号唤醒，但是可以被致命信号唤醒，醒后即死。...实际上，当Linux内核发现进程（线程组）收到了一个sig_fatal()的信号的时候，会给这个进程中的每个线程人为地插入一个SIGKILL信号，这个从while_each_thread循环可以看出。...有的童鞋说，如果我的进程只有一个线程呢？那去掉上图中的T2以及T2独占的signal pending框即可： ? 为了进行验证，我们不再使用cat。
在使用时将其当做成一个普通队列数据结构，只不过等待队列是若干个休眠进程的集合，且内核自己实现了此队列初始化队列、入队列、出队列的一系列API，在使用时只需要调用系统的API即可。...自动睡眠 Linux 内核中睡眠的最简单方式是一个宏定义, 称为 wait_event(有几个变体); 它结合了处理睡眠的细节和进程在等待的条件的检查. wait_event 的形式是: queue...schedule()，进程调度，而schedule_timeout()进行调度之后，一定时间后自动唤醒(超时唤醒)，若唤醒后，condition仍然为假，则继续睡眠，反之执行。...3.4 唤醒 当进程进入等待队列休眠时，其他进程可以主动叫等待队列头唤醒首个等待队列项。若为自动睡眠，先判断condition：若为真则执行，否则继续睡眠。...等待队列： 是将当前进程先休眠，直到该进程被其他进程唤醒才可执行，且有超时唤醒功能。 2020-06-27
如何从Linux 0.11的这个队列中唤醒?...因此，需要给信号增添新的语义，增添新语义后的信号，被称为信号量。 ---- 从信号到信号量 不只是等待信号、发信号? 对应睡眠和唤醒!...0.11那里学点东西… 我们以Linux 0.11读磁盘为例，来看看Linux 0.11中是如何实现对信号量的使用和保护的: 从磁盘中读取一个磁盘块到内存的过程是先在内存中申请一块缓冲区用来存放读取出来的磁盘块...---- 如何从Linux 0.11的这个队列中唤醒?...这样只要执行一次wake_up()操作，就可以依次将所有等待在信号量sem处的睡眠进程唤醒。
写入进程实际处于可中断的等待状态，当内存中有足够的空间可以容纳写入数据，或内存被解锁时，读取进程会唤醒写入进程，这时，写入进程将接收到信号。...通常发生在两种情况下： 当前进程由于系统调用、中断或异常而进入内核空间以后，从内核空间返回到用户空间前夕； 当前进程在内核中进入睡眠以后刚被唤醒的时候，由于检测到信号的存在而提前返回到用户空间。...这里要补充的是， 如果信号发送给一个正在睡眠的进程，那么要 看该进程进入睡眠的优先级，如果进程睡眠在可被中断的优先级上，则唤醒进程； 否则仅设置进程表中信号域相应的位，而不唤醒进程。...第三个要注意的地方：若进程睡眠在可中断的优先级上，则当它收到一个要忽略的信号时，该进程被唤醒，但不做longjmp，一般是继续睡眠。 但用户感觉不 到进程曾经被唤醒，而是象没有发生过该信号一样。...SIGCLD信号的作用是唤醒一个睡眠在可被中断优先级上的进程。 如果该进程捕捉了这个信号，就象普通信号处理一样转到处理例程。 如果进程忽略该信号，则 什么也不做。
这意味着在使用自旋锁获得某一信号量的进程会出现对处理器拥有权的丧失，也即时进程切换出处理器。信号量一般用于进程上下文，自旋锁一般用于中断上下文。...wait_list： 用于管理所有在获取该信号量时候进入睡眠的进程，将这些进程加入到wait_list中。 从上述的信号量定义处看见注释： 不要直接的访问信号量的任何成员。...当该进程再一次被调度执行时，需要根据被再次调度的原因进行处理： 如果是witer.up不为0, 说明睡眠的该进程被信号量执行了UP操作所唤醒，进程可以获取信号量，返回0....如果sem->wait_list不为空，说明有进程正在睡眠在wait_list上等待信号量，此时需要调用__up函数来唤醒进程。...wake_up_process(waiter->task); 调用wake_up_process唤醒该进程。 使用信号量实现互斥 当信号量的count=1的时候，这种情况下就可以实现互斥机制。
TASK_INTERRUPTIBLE状态的进程可以被wake_up和信号唤醒。唤醒的时候也是通过修改进程的状态为可运行，然后等待下一次进程调度，被唤醒的进程不一定马上得到执行。...} // 当前进程挂载到睡眠队列p中，p指向队列头指针的地址 void sleep_on(struct task_struct **p) { struct task_struct *tmp;...，即tmp指向第一个睡眠节点 头指针指向当前进程，这个版本的实现没有采用真正链表的形式， 他通过每个进程在栈中的临时变量形成一个链表，每个睡眠的进程， 在栈里有一个变量指向后面一个睡眠节点...，可以通过wake_up和接收信号唤醒，不可中断的时候， 能保证唤醒的时候，是从前往后逐个唤醒,但是可中断睡眠无法保证这一点， 因为进程可能被信号唤醒了，所以需要判断全局指针是否指向了自己...* 这里为true，说明是信号唤醒，因为wake_up能保证唤醒的是第一个节点， 这里先唤醒链表中比当前进程后插入链表的节点，有点奇怪，自己被信号唤醒了，
也就是说，如果给一个TASK_INTERRUPTIBLE状态的进程发送SIGKILL信号，这个进程将先被唤醒（进入TASK_RUNNING状态），然后再响应SIGKILL信号而退出（变为TASK_DEAD...并不会从TASK_INTERRUPTIBLE状态直接退出。 进程从非TASK_RUNNING状态变为TASK_RUNNING状态，是由别的进程（也可能是中断处理程序）执行唤醒操作来实现的。...执行唤醒的进程设置被唤醒进程的状态为TASK_RUNNING，然后将其task_struct结构加入到某个CPU的可执行队列中。于是被唤醒的进程将有机会被调度执行。 ...当这些事件发生时（由外部中断触发、或由其他进程触发），对应的等待队列中的一个或多个进程将被唤醒。...但是使用task_struct结构更为方便，因为在内核中已经建立了从pid到task_struct查找关系，还有进程间的父子关系。
现在，我们来看看内核如何将进程置为睡眠状态。 内核如何将进程置为睡眠状态 Linux 内核提供了两种方法将进程置为睡眠状态。...这样会将进程从 CPU 运行队列中移除。...如果进程处于可中断模式的睡眠状态（通过将其状态设置为 TASK_INTERRUPTIBLE），那么可以通过显式的唤醒呼叫（wakeup_process()）或需要处理的信号来唤醒它。...因此，懒惰的程序员可能比较喜欢将进程置为不可中断模式的睡眠状态，因为信号不会唤醒这类任务。...而TASK_WAKEKILL 用于在接收到致命信号时唤醒进程 新的睡眠状态允许 TASK_UNINTERRUPTIBLE 响应致命信号 进程状态的切换过程和原因大致如下图 ?
这些进程的task_struct结构（进程控制块）被放入对应事件的等待队列中。当这些事件发生时（由外部中断触发、或由其他进程触发），对应的等待队列中的一个或多个进程将被唤醒。...否则你将惊奇的发现，kill -9竟然杀不死一个正在睡眠的进程了！...也就是说，如果给一个TASK_INTERRUPTIBLE状态的进程发送SIGKILL信号，这个进程将先被唤醒（进入TASK_RUNNING状态），然后再响应SIGKILL信号而退出（变为TASK_DEAD...并不会从TASK_INTERRUPTIBLE状态直接退出。 进程从非TASK_RUNNING状态变为TASK_RUNNING状态，是由别的进程（也可能是中断处理程序）执行唤醒操作来实现的。...执行唤醒的进程设置被唤醒进程的状态为TASK_RUNNING，然后将其task_struct结构加入到某个CPU的可执行队列中。于是被唤醒的进程将有机会被调度执行。
1 进程总览 进程是对逻辑的抽象，我们从操作系统的书籍中对进程有了很多的认识，但是对进程的实现可能不太了解，这篇文章尝试解释一下关于进程实现的大致原理。...根据tss信息中的ldt索引首先从GDT找到进程ldt结构体数据的首地址，然后根据当前段的属性，比如代码段，则从cs中取得选择子，系统从ldt表中取得进程线性空间的首地址、限长、权限等信息。...在这里插入图片描述 当管道有内容写入的时候，进程被唤醒。进程被挂起（分为可被信号唤醒和不能被信号唤醒两种）和唤醒的实现。...，即tmp指向第一个睡眠节点 头指针指向当前进程，这个版本的实现没有采用真正链表的形式， 他通过每个进程在栈中的临时变量形成一个链表，每个睡眠的进程， 在栈里有一个变量指向后面一个睡眠节点...*/ tmp = *p; *p = current; // 不可中断睡眠只能通过wake_up唤醒，即使有信号也无法唤醒 current->state = TASK_UNINTERRUPTIBLE
同样，消费者从缓冲区中取数据发现缓冲区中数据个数为0，那么消费者就会睡眠，当生产者发现缓冲区的数据增加到1时，生产者会再唤醒消费者。 但这里存在竞争条件。...当count从N降为N-1时，消费者唤醒生产者；当count从0变为1时，生产者唤醒消费者。 为什么会出现竞争条件呢？本质的原因是会存在发送给一个尚未睡眠的进程/线程的信号丢失了。...生产者生产一项数据并放入共享缓冲区，此时count从0 变为 1，所以生产者认为刚才消费者读取了count为0，此时消费者肯定在睡眠，于是生产者就调用weakUp唤醒消费者。...可以用信号量解决丢失的weakUp问题。信号量是一个整型变量，用来累计进程/线程被唤醒的次数，供将来使用。信号量大于0时，代表将要有一个或多个唤醒操作；信号量为0时，代表没有唤醒操作。...因为信号量从0变为1时，系统会选择一个等待该信号量的进程获得该信号量，获得该信号量的进程会对该信号量减一，然后该进程不再睡眠，继续执行。
对于"就绪-->睡眠",等待中的进程本就已经进入了等待队列，表示可运行，而进入睡眠态表示暂时不可运行，这本身就是冲突的；对于"睡眠-->运行"这也是行不通的，因为调度类只会从等待队列中挑出下一次要运行的进程...再说说运行态-->睡眠态。从运行态到睡眠态一般是等待某事件的出现，例如等待信号通知，等待IO完成。...可中断睡眠是允许接收外界信号和内核信号而被唤醒的睡眠，绝大多数睡眠都是可中断睡眠，能ps或top捕捉到的睡眠也几乎总是可中断睡眠；不可中断睡眠只能由内核发起信号来唤醒，外界无法通过信号来唤醒，主要表现在和硬件交互的时候...例如cat一个文件时，从硬盘上加载数据到内存中，在和硬件交互的那一小段时间一定是不可中断的，否则在加载数据的时候突然被人为发送的信号手动唤醒，而被唤醒时和硬件交互的过程又还没完成，所以即使唤醒了也没法将...在cp这个子进程执行过程中，父进程bash会进入睡眠状态(不仅是因为cpu只有一颗的情况下一次只能执行一个进程，还因为进程等待)，并等待被唤醒，此刻bash无法和人类交互。
然后wakeup将看到睡眠进程并将其唤醒（除非有其他东西首先将其唤醒）。 有时，多个进程在同一个通道上睡眠: 例如，多个进程读取同一个管道。一个单独的wakeup调用就能把他们全部唤醒。...其中一个将首先运行并获取与sleep一同调用的锁，并且（在管道例子中）读取在管道中等待的任何数据。尽管被唤醒，其他进程将发现没有要读取的数据。从他们的角度来看，醒来是“虚假的”，他们必须再次睡眠。...如果受害者进程在sleep中，kill对wakeup的调用将导致受害者从sleep中返回。这存在潜在的危险，因为等待的条件可能不为真。...Plan 9的sleep使用一个回调函数，该函数在马上睡眠时获取调度锁，并在运行中持有；该函数用于在最后时刻检查睡眠条件，以避免丢失唤醒。...用信号量取代xv6中sleep和wakeup的使用。判断结果。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
