实时分为硬实时和软实时，硬实时要求绝对保证响应时间不超过期限，如果超过期限，会造成灾难性的后果，例如汽车在发生碰撞事故时必须快速展开安全气囊；软实时只需尽力使响应时间不超过期限，如果偶尔超过期限，不会造成灾难性的后果.
要深入理解Linux内核中的同步与互斥的实现，需要先了解一下内联汇编：在C函数中使用汇编代码。
实时系统要求对事件的响应时间不能超过规定的期限，响应时间是指从某个事件发生到负责处理这个事件的进程处理完成的时间间隔，最大响应时间应该是确定的、可以预测的。
在现代操作系统里，同一时间可能有多个内核执行流在执行，因此内核其实像多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问，尤其是在多处理器系统上，更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问。在主流的Linux内核中包含了如下这些同步机制包括：
所谓惊群现象,简单的来说就是当多个进程或线程在同时阻塞等待同一个事件时,如果该事件发生,会唤醒在等待的所有的进程/线程,但最终只可能有一个进程/线程对该事件进行处理,其他进程/线程会在失败后重新休眠,唤醒多个进程/线程这种不必要的行为会造成系统资源的浪费(涉及到进程的上下文切换)。而常见的惊群问题有accept惊群、epoll惊群。
我其实并不想讨论微内核的概念，也并不擅长去阐述概念，这是百科全书的事，但无奈最近由于鸿蒙的发布导致这个话题过火，也就经不住诱惑，加上我又一直比较喜欢操作系统这个话题，就来个老生常谈吧。
这个事情很奇怪，我不觉得它提出来的Possible unsafe locking scenario真的会死锁啊。
阻塞同步有许多实现方式了：mutex, semaphore. 阻塞同步使用不当就可能造成死锁，活锁，优先级反转。
对于信号量我们并不陌生。信号量在计算机科学中是一个很容易理解的概念。本质上，信号量就是一个简单的整数，对其进行的操作称为PV操作。进入某段临界代码段就会调用相关信号量的P操作；如果信号量的值大于0，该值会减1，进程继续执行。相反，如果信号量的值等于0，该进程就会等待，直到有其它程序释放该信号量。释放信号量的过程就称为V操作，通过增加信号量的值，唤醒正在等待的进程。
在《宋宝华：火焰图：全局视野的Linux性能剖析》一文中，我们主要看了on-cpu火焰图，理解了系统的CPU的走向的分析。但是，很多时候，单纯地看on-cpu的情况（什么代码在耗费CPU），并不能解决性能问题，因为有时候性能差的原因瓶颈不一定在CPU上面，而是在off-cpu的时间，比如：
之前在Linux系统移植时提到过LCD驱动，本篇来看下Linux设备树如何配置LCD驱动。
大家好，我是程栩，一个专注于性能的大厂程序员，分享包括但不限于计算机体系结构、性能优化、云原生的知识。
内核模块是Linux操作系统中一个比较独特的机制。通过这一章学习，希望能够理解Linux提出内核模块这个机制的意义；理解并掌握Linux实现内核模块机制的基本技术路线；运用Linux提供的工具和命令，掌握操作内核模块的方法。
现如今，一个服务端应用程序几乎都会使用到多线程来提升服务性能，而目前服务端还是以linux系统为主。一个多线程的java应用，不管使用了什么样的同步机制，最终都要用JVM执行同步处理，而JVM本身也是linux上的一个进程，那么java应用的线程同步机制，可以说是对操作系统层面的同步机制的上层封装。这里我说的操作系统，主要是的非实时抢占式内核（non-PREEMPT_RT），并不讨论实时抢占式内核（PREEMPT_RT） 的问题，二者由于使用场景不同，因此同步机制也会存在差异或出现变化。
进程与线程之间是有区别的，不过linux内核只提供了轻量进程的支持，未实现线程模型。Linux是一种“多进程单线程”的操作系统。Linux本身只有进程的概念，而其所谓的“线程”本质上在内核里仍然是进程。
刚开始接触go时，发现go程序和php程序的其中一个不同是php是解释性语言，go是编译型语言，即每次在有程序改动后，需要重新运行 go run或go build进行重新编译，更改才能生效，实则不便。于是乎在网络上搜索发现了gowatch这个包，该包可通过监听当前目录下相关文件的变动，对go文件实时编译，提高研发效率。那gowatch又是如何做到监听文件变化的呢？
《手摸手系列》把go sync包中的并发组件已经写完了，本文作为完结篇，最后再来探讨下go运行时锁的实现。记得在《手摸手Go 并发编程的基建Semaphore》那篇中我们聊过sync.Mutex最终是依赖sema.go中实现的sleep和wakeup原语来实现的。如果细心的小伙伴会发现:
一、UDEV是什么？ Udev是一个针对Linux内核2.6的可提供自动创建的设备节点和命名的解决方法的一个文件系统；其实与/etc/目录下的fstab文件类似 二、Udev如何获取内核这些模块的变化信息？ 参考博客：http://blog.chinaunix.net/uid-24943863-id-3223000.html 设备节点的创建，是通过sysfs接口分析dev文件取得设备节点号，这个很显而易见。那么udevd是通过什么机制来得知内核里模块的变化情况，如何得知设备的插入移除情况呢？当然是通过hot
所谓实时，就是一个特定任务的执行时间必须是确定的，可预测的，并且在任何情况下都能保证任务的时限（最大执行时间限制）。实时又分软实时和硬实时，所谓软实时，就是对任务执行时限的要求不那么严苛，即使在一些情况下不能满足时限要求，也不会对系统本身产生致命影响，例如，媒体播放系统就是软实时的，它需要系统能够在1秒钟播放24帧，但是即使在一些严重负载的情况下不能在1秒钟内处理24帧，也是可以接受的。所谓硬实时，就是对任务的执行时限的要求非常严格，无论在什么情况下，任务的执行实现必须得到绝对保证，否则将产生灾难性后果，例如，飞行器自动驾驶和导航系统就是硬实时的，它必须要求系统能在限定的时限内完成特定的任务，否则将导致重大事故，如碰撞或爆炸等。
单例模式，是一种常用的软件设计模式，在它的核心结构中只包含一个被称为单例的特殊类。通过单例模式可以保证系统中一个类只有一个实例且该实例易于外界访问，从而方便对实例个数的控制并节约系统资源。 懒汉模式（Lazy Loading） 懒汉模式是开源项目中使用最多的一种，最大的缺点是非线程安全的 type singleton struct { } // private var instance *singleton // public func GetInstance() *singleton { if
idr在linux内核中指的就是整数ID管理机制，从本质上来说，这就是一种将整数ID号和特定指针关联在一起的机制。这个机制最早是在2003年2月加入内核的，当时是作为POSIX定时器的一个补丁。现在，在内核的很多地方都可以找到idr的身影。
之前负责过QQ音乐Android版的播放功能，对于Android音频系统有过一些了解，因此将这些内容整理成文。本文是Android音频系统的基础篇，主要介绍了匿名内存内部实现以及对外的接口。下篇文章将介绍Ashmem对外提供的接口以及MemoryBase+MemoryHeapBase实现进程间共享内存的原理。
RCU（Read-Copy Update）是数据同步的一种方式，在当前的Linux内核中发挥着重要的作用。RCU主要针对的数据对象是链表，目的是提高遍历读取数据的效率，为了达到目的使用RCU机制读取数据的时候不对链表进行耗时的加锁操作。这样在同一时间可以有多个线程同时读取该链表，并且允许一个线程对链表进行修改（修改的时候，需要加锁）。RCU适用于需要频繁的读取数据，而相应修改数据并不多的情景，例如在文件系统中，经常需要查找定位目录，而对目录的修改相对来说并不多，这就是RCU发挥作用的最佳场景。 Linux内核源码当中,关于RCU的文档比较齐全，你可以在 /Documentation/RCU/ 目录下找到这些文件。Paul E. McKenney 是内核中RCU源码的主要实现者，他也写了很多RCU方面的文章。他把这些文章和一些关于RCU的论文的链接整理到了一起。http://www2.rdrop.com/users/paulmck/RCU/ 在RCU的实现过程中，我们主要解决以下问题： 1，在读取过程中，另外一个线程删除了一个节点。删除线程可以把这个节点从链表中移除，但它不能直接销毁这个节点，必须等到所有的读取线程读取完成以后，才进行销毁操作。RCU中把这个过程称为宽限期（Grace period）。 2，在读取过程中，另外一个线程插入了一个新节点，而读线程读到了这个节点，那么需要保证读到的这个节点是完整的。这里涉及到了发布-订阅机制（Publish-Subscribe Mechanism）。 3， 保证读取链表的完整性。新增或者删除一个节点，不至于导致遍历一个链表从中间断开。但是RCU并不保证一定能读到新增的节点或者不读到要被删除的节点。 宽限期
Ingo Molnar 的实时补丁是完全开源的，它采用的实时实现技术完全类似于Timesys Linux，而且中断线程化的代码是基于TimeSys Linux的中断线程化代码的。这些实时实现技术包括：中断线程化（包括IRQ和softirq）、用Mutex取代spinlock、优先级继承和死锁检测、等待队列优先级化等。
综述 在上一篇介绍了linux驱动的调试方法，这一篇介绍一下在驱动编程中会遇到的并发和竟态以及如何处理并发和竞争。 首先什么是并发与竟态呢？并发(concurrency)指的是多个执行单元同时、并行被执行。而并发的执行单元对共享资源(硬件资源和软件上的全局、静态变量)的访问则容易导致竞态(race conditions)。可能导致并发和竟态的情况有： SMP（Symmetric Multi-Processing），对称多处理结构。SMP是一种紧耦合、共享存储的系统模型，它的特点是多个CPU使用共同的系统总线
在早期的 Linux内核中，并发的来源相对较少。早期内核不支持对称多处理（ symmetric multi processing,SMP），因此，导致并发执行的唯一原因是对硬件中断的服务。这种情况处理起来较为简单，但并不适用于为获得更好的性能而使用更多处理器且强调快速响应事件的系统。
cgroups是Linux下控制一个（或一组）进程的资源限制机制，全称是control groups，可以对cpu、内存等资源做精细化控制，比如目前很多的Docker在Linux下就是基于cgroups提供的资源限制机制来实现资源控制的；除此之外，开发者也可以指直接基于cgroups来进行进程资源控制，比如8核的机器上部署了一个web服务和一个计算服务，可以让web服务仅可使用其中6个核，把剩下的两个核留给计算服务。cgroups cpu限制除了可以限制使用多少/哪几个核心之外，还可以设置cpu占用比（注意占用比是各自都跑满情况下的使用比例，如果一个cgroup空闲而另一个繁忙，那么繁忙的cgroup是有可能占满整个cpu核心的）。
文件的写入是否是原子的？多个线程写入同一个文件是否会写错乱?多个进程写入同一个文件是否会写错乱？想必这些问题多多少少会对我们产生一定的困扰，即使知道结果，很多时候也很难将这其中的原理清晰的表达给提问者
相比于select，epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。 并且，在linux/posix_types.h头文件有这样的声明： #define __FD_SETSIZE 1024 表示select最多同时监听1024个fd，当然，可以通过修改头文件再重编译内核来扩大这个数目，但这似乎并不治本。
惊群效应也有人叫做雷鸣群体效应，不过叫什么，简言之，惊群现象就是多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），如果等待的这个事件发生，那么他就会唤醒等待的所有进程（或者线程），但是最终却只可能有一个进程（线程）获得这个时间的“控制权”，对该事件进行处理，而其他进程（线程）获取“控制权”失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群。
许多人都认为Linux是最安全的操作系统，因此在对Linux的安全问题上也放松了警惕。那么事实真的如此吗？其实安全从来都只是相对的，Linux也不例外。虽然它加载了强大的安全机制，但仍可能受到来自各方面带来的安全威胁。本文我们主要将讨论有关Linux架构的主要利用技术，以及相关的安全防御措施。
最近在搞IoT的时候，因为没有设备，模拟跑固件经常会缺/dev/xxx，所以我就开始想，我能不能自己写一个驱动，让固件能跑起来？因此，又给自己挖了一个很大坑，不管最后能不能达到我的初衷，能学到怎么开发Linux驱动，也算是有很大的收获了。
Linux 内核中的同步机制：原子操作、信号量、读写信号量、自旋锁的API、大内核锁、读写锁、大读者锁、RCU和顺序锁。 1、介绍 在现代操作系统里，同一时间可能有多个内核执行流在执行，即使单CPU内核也需要一些同步机制来同步不同执行单元对共享的数据的访问。 主流的Linux内核中的同步机制包括： 原子操作 信号量（semaphore） 读写信号量（rw_semaphore） 自旋锁spinlock 大内核锁BKL(Big Kernel Lock) 读写锁rwlock、 brlock（只包含在2.4内核中
本质上，Ext3 mount的过程实际上是inode被替代的过程。例如，/dev/sdb块设备被mount到/mnt/alan目录。那么mount这个过程所需要解决的问题就是将/mnt/alan的dentry目录项所指向的inode屏蔽掉，然后重新定位到/dev/sdb所表示的inode索引节点。在没有分析阅读linux vfs mount代码的时候，我的想法是修改dentry所指向的inode索引节点，以此实现mount文件系统的访问。经过分析，在实际的vfs mount实现过程中，还是和我原始的想法略有差别，但是，基本目标还是相同的。
死锁指两个或更多进程或线程因相互等待对方释放资源而互相阻塞，从而导致系统中所有的进程或线程都无法继续运行的情况。
关于调度时机，网上的文章也五花八门，之前在内核抢占文章已经做了详细讲解，而在本文我们从源码注释中给出依据（再次强调一下：本文的调度时机关注的是何时调用主调度器，不是设置重新调度标志的时机，之前讲解中我们知道他们都可以称为调度时机）。
Linux内核通过一个被称为进程描述符的task_struct结构体来管理进程，这个结构体包含了一个进程所需的所有信息。它定义在include/linux/sched.h文件中。
Linux内核有多种锁机制，比如 自旋锁、信号量 和 读写锁 等。不同的场景使用不同的锁，如在读多写少的场景可以使用读写锁，而在锁粒度比较小的场景可以使用自旋锁。
RCU（Read-Copy Update） RCU就是指读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读操作不需要获得任何锁就可以访问，但写操作在访问它时首先拷贝一个副本，然后对副本进行修改，最后在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。 Linux内核中内存管理大量的运用到了RCU机制。为每个内存对象增加了一个原子计数器用来继续该对象当前访问数。当没有其他进程在访问该对象时（计数器为0），才允许回收该内存。 从
容器追踪模块的ebpf代码服用了process追踪模块的ebpf代码，因此这里我们只介绍用户态下对数据处理的设计。 当内核态捕捉到进程的数据返回到用户态时，我们调用judge_container()函数，判断该进程是否归属于一个container，其具体实现为：
1、简介： RCU（Read-Copy Update）是数据同步的一种方式，在当前的Linux内核中发挥着重要的作用。 RCU主要针对的数据对象是链表，目的是提高遍历读取数据的效率，为了达到目的使用RCU机制读取数据的时候不对链表进行耗时的加锁操作。这样在同一时间可以有多个线程同时读取该链表，并且允许一个线程对链表进行修改（修改的时候，需要加锁）。 2、应用场景： RCU适用于需要频繁的读取数据，而相应修改数据并不多的情景，例如在文件系统中，经常需要查找定位目录，而对目录的修改相对来说并不多，这就是RCU发
传统的服务器使用“listen-accept-创建通信socket”完成客户端的一次请求服务。在高并发服务模型中，服务器创建很多进程-单线程（比如apache mpm）或者n进程：m线程比例创建服务线程（比如nginx event）。机器上运行着不等数量的服务进程或线程。这些进程监听着同一个socket。这个socket是和客户端通信的唯一地址。服务器父子进程或者多线程模型都accept该socket，有几率同时调用accept。当一个请求进来，accept同时唤醒等待socket的多个进程，但是只有一个进程能accept到新的socket，其他进程accept不到任何东西，只好继续回到accept流程。这就是惊群效应。如果使用的是select/epoll+accept，则把惊群提前到了select/epoll这一步，多个进程只有一个进程能acxept到连接，因为是非阻塞socket，其他进程返回EAGAIN。
在linux内核系统中，各个模块、子系统之间是相互独立的。Linux内核可以通过通知链机制来获取由其它模块或子系统产生的它感兴趣的某些事件。
fork是一个拥有50年历史的陈年系统调用，它是一个传奇！时至今日，它依旧灿烂。
文章主要介绍了在Linux系统中，如何利用自旋锁来实现线程之间的同步和互斥。主要包括了自旋锁的定义、工作原理、使用方式和注意事项，并通过实例介绍了如何在C语言中实现自旋锁。
例如，用户运行自己的程序，系统就创建一个进程，并为它分配资源，包括各种表格、内存空间、磁盘空间、I／O设备等。
谈到Redis缓存，我们描述其性能时会这么说：支持1万并发连接，几万QPS。而我们描述Nginx的高性能时，则会宣示：支持C10M（1千万并发连接），百万级QPS。Nginx用C语言开发，而Redis是用同一家族的C++语言开发的，C与C++在性能上是同一级数的。Redis与Nginx同样使用了事件驱动、异步调用、Epoll这些机制，为什么Nginx的并发连接会高出那么多呢？（本文不讨论Redis分布式集群）
尽管信号量已经可以实现互斥的功能，但是“正宗”的mutex在Linux内核中还是真实地存在着。尤其是在Linux内核代码中，更多能看到mutex的身影。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
