如果要使用 " 内存屏障 " , 如 : 禁止 内核 抢占 " 方法保护临界区 " :
在有了强大的spin lock之后，为何还会有rw spin lock呢？无他，仅仅是为了增加内核的并发，从而增加性能而已。spin lock严格的限制只有一个thread可以进入临界区，但是实际中，有些对共享资源的访问可以严格区分读和写的，这时候，其实多个读的thread进入临界区是OK的，使用spin lock则限制一个读thread进入，从而导致性能的下降。
本文讲述了Linux中RCU（Read-Copy-Update）机制在内存管理中的重要作用，以及如何在Linux内核中实现和管理RCU。在Linux内核中，RCU用于在多个进程共享相同内存空间时，保证这些进程之间的数据一致性。本文首先介绍了RCU的基本原理，然后逐步深入介绍了Linux内核中RCU的实现细节。最后，通过一个具体的例子，展示了如何在Linux内核中实现一个简单的RCU。
实时分为硬实时和软实时，硬实时要求绝对保证响应时间不超过期限，如果超过期限，会造成灾难性的后果，例如汽车在发生碰撞事故时必须快速展开安全气囊；软实时只需尽力使响应时间不超过期限，如果偶尔超过期限，不会造成灾难性的后果.
如果需要多个进程合作来完成某个任务，那个可能会存在资源争用或者其他一些意想不到的问题，这个时候，就需要通过实现进程同步来防止问题的产生。
在 Linux 系统中，当多个线程并行执行时，如果需要访问同一个资源，那么在访问资源的地方，需要使用操作系统为我们提供的同步原语来进行保护。同步原语包括：互斥锁、条件变量、信号量等，被保护的代码称作“临界区”。
上面讲的自旋锁，信号量和互斥锁的实现，都是使用了原子操作指令。由于原子操作会 lock，当线程在多个 CPU 上争抢进入临界区的时候，都会操作那个在多个 CPU 之间共享的数据 lock。CPU 0 操作了 lock，为了数据的一致性，CPU 0 的操作会导致其他 CPU 的 L1 中的 lock 变成 invalid，在随后的来自其他 CPU 对 lock 的访问会导致 L1 cache miss（更准确的说是communication cache miss），必须从下一个 level 的 cache 中获取。
自旋锁：如果内核配置为SMP系统，自旋锁就按SMP系统上的要求来实现真正的自旋等待，但是对于UP系统，自旋锁仅做抢占和中断操作，没有实现真正的“自旋”。如果配置了CONFIG_DEBUG_SPINLOCK，那么自旋锁按照SMP系统来编译。
实时系统要求对事件的响应时间不能超过规定的期限，响应时间是指从某个事件发生到负责处理这个事件的进程处理完成的时间间隔，最大响应时间应该是确定的、可以预测的。
这两天看进程的同步与通信，看了几本书上的介绍，也从网上搜了很多资料，越看越迷惑，被这几个问题搞得很纠结。
Linux 内核有非常多的锁机制，如：自旋锁、读写锁、信号量和 RCU 锁等。本文介绍一种和读写锁比较相似的锁机制：顺序锁（seqlock）。
用于进程间传递信号的一个整数值。在信号量上只有三种操作可以进行：初始化，P操作和V操作，这三种操作都是原子操作。
前面学习了spin_lock可以知道，spin_lock对于临界区是不做区分的。而读写锁是对临界区做读写区分，并且度进程进入临界区的几率比较大，因为写进程进入时需要等待读进程退出临界区。而有没有一种方法，可以保护写进程的优先权，使得写进程可以更快的获得锁？ 答案是有的，就是顺序锁。
阅读前面的文章，我们已经知道了进程是操作系统对正在运行的程序的抽象。现代操作系统中，进程通常需要和其他进程进行通信。我们称之为进程间通信 问题。又叫做IPC（Inter Process Communication） 问题。IPC主要解决以下3个问题：
在多年前，linux还没有支持对称多处理器SMP的时候，避免并发数据访问相对简单。
函数原型:int semop(int semid, struct sembuf *sops, unsigned nsops);
我们可以把内核想象成一个服务器，专门响应各种请求。这些请求可以是CPU上正在运行的进程发起的请求，也可以是外部的设备发起的中断请求。所以说，内核并不是串行运行，而是交错执行。既然是交错执行，就会产生竞态条件，我们可以采用同步技术消除这种竞态条件。
我们假定有两个线程来分别从银行卡和存折进行取款操作，当A线程执行完判断语句后，获得了当前账户中的余额数（1000元），因为余额大于取款金额，所以准备执行取钱操作（从账户中减去1000元），但此时它被线程B打断，然后，线程B根据余额（1000），从中取出1000元，然后，将账户里面的余额减去1000元，然后，返回执行线程A的动作，这个线程将从上次中断的地方开始执行：也就是说，它将不再判断账户中的余额，而是直接将上次中断之前获得的余额减去1000。此时，经过两次的取款操作，账户中的余额为100元，从账面上来看，银行支出了1000元，但实际上，银行支出了2000元。
load ：将共享变量ticket从内存加载到寄存器中 update : 更新寄存器里面的值，执行-1操作 store ：将新值，从寄存器写回共享变量ticket的内存地址
critical section是每个线程中访问临界资源的那段代码，不论是硬件临界资源，还是软件临界资源，多个线程必须互斥地对它进行访问。 资源竞速就是可能在由于在访问临界区时没有互斥的访问而导致的特殊情况。
Read-copy update (RCU) 是一种 2002 年 10 月被引入到内核当中的同步机制。通过允许在更新的同时读数据，RCU 提高了同步机制的可伸缩性（scalability）。相对于传统的在并发线程间不区分是读者还是写者的简单互斥性锁机制，或者是哪些允许并发读但同时不 允许写的读写锁，RCU 支持同时一个更新线程和多个读线程的并发。RCU 通过保存对象的多个副本来保障读操作的连续性，并保证在预定的读方临界区没有完成之前不会释放这个对象。RCU定义并使用高效、可伸缩的机制来发布并读取 对象的新版本，并延长旧版本们的寿命。这些机制将工作分发到了读和更新路径上，以保证读路径可以极快地运行。在某些场合（非抢占内核），RCU 的读方没有任何性能负担。
一.单标志法 轮流交替使用。 缺点:当有一个进程不再进入临界区，便不能修改公共变量的turn，来标识另外一个进程可以进入临界区。因此另外一个进程将永久不能进入临界区，违背“空则让进”的原则
Linux互斥与同步 零、前言 一、Linux线程互斥 1、基本概念及引入 2、互斥量mutex介绍 3、互斥量的使用 4、互斥量原理 二、可重入/线程安全 1、基本概念 2、线程安全 3、重入函数 4、联系与区别 三、常见锁概念 四、Linux线程同步 1、基本概念 2、条件变量的使用 3、条件变量等待 4、条件变量使用规范 五、POSIX信号量 1、信号量概念及介绍 2、信号量的使用 零、前言 本章主要讲解学习Linux中对多线程的执行中的同步与互斥 一、Linux线程互斥 1、基本概念及引入 互
但进程的异步性在有些情况下可能会影响程序的正常运行，以上图的管道通信为例，进程1负责写入数据，进程2负责读取数据，只有进程1将管道数据填满后进程2才能成功取到数据，但两个进程并发执行，无法确定读写数据操作的先后顺序，而实际情况又要求必须先写后读的方式执行，此时就需要通过进程同步解决相关问题
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
关于同步理论的一些基本概念 临界区（critical area）: 访问或操作共享数据的代码段 简单理解：synchronized大括号中部分（原子性） 竞争条件（race conditions）两个线程同时拥有临界区的执行权 数据不一致：（data unconsistency） 由竞争条件引起的数据破坏 同步（synchronization）避免race conditions 锁：完成同步的手段（门锁，门后是临界区，只允许一个线程存在） 上锁解锁必须具备原子性 原子性（象原子一样不可分割的操作） 有序
操作系统中存在多个进程并发访问和操作同一个数据，并且执行结果和进程执行的特定顺序有关，称为：竞争条件。为了防止竞争条件发生，我们需要确保一段时间内只有一个进程能操作这个数据。为了实现这个保证，进程之间必须要同步。
重量级锁就是如果存在线程竞争，会把线程 挂起来，等其他线程释放锁后，再去唤醒挂起的线程。因为线程的挂起和唤醒需要从内核态到用户态的切换，这个切换需要操作系统的支持，性能消耗非常大。
EnterCriticalSection和LeaveCriticalSection是干嘛用的？
上一篇笔记我们已经讲了进程的相关概念和进程控制的知识，这篇笔记则涉及到了进程同步与进程互斥。
同步是指协调多个执行线程或进程的执行，以确保它们按照一定的顺序执行或在特定的条件下等待。常见的同步机制包括信号量、条件变量和屏障等。
在早期的 Linux内核中，并发的来源相对较少。早期内核不支持对称多处理（ symmetric multi processing,SMP），因此，导致并发执行的唯一原因是对硬件中断的服务。这种情况处理起来较为简单，但并不适用于为获得更好的性能而使用更多处理器且强调快速响应事件的系统。
大家好，又见面了，我是你们的朋友全栈君。 当多个线程访问一个独占性共享资源时,可以使用“临界区”对象。任一时刻只有一个线程可以拥有临界区对象，拥有临界区的线程可以访问被保护起来的资源或代码段，其他希望进入临界区的线程将被挂起等待，直到拥有临界区的线程放弃临界区时为止，这样就保证了不会在同一时刻出现多个线程访问共享资源。
本文简介本文介绍Linux RCU的基本概念。这不是一篇单独的文章，这是《谢宝友：深入理解Linux RCU》系列的第3篇，前序文章：谢宝友： 深入理解Linux RCU之一——从硬件说起= 谢宝友：
原子变量适用在多核之间多单一共享变量进行互斥访问，如果要保护多个变量，并且这些变量之间有逻辑关系时，原子变量就不适用了。例如：常见的双向链表。假设有三个链表节点Ａ、Ｂ、Ｃ。需要将节点Ｂ插入节点Ａ、Ｃ之间。如果ＣＰＵ Ａ刚好将Ａ节点的后向指针指向Ｂ，但是还没有将Ｂ的后向指针指向Ｃ。此时ＣＰＵ Ｂ要遍历链表，这将会一个灾难性的后果。
空闲让进 当无进程处于临界区，可允许一个请求进入临界区的进程立即进入自己的临界区
综述 在上一篇介绍了linux驱动的调试方法，这一篇介绍一下在驱动编程中会遇到的并发和竟态以及如何处理并发和竞争。 首先什么是并发与竟态呢？并发(concurrency)指的是多个执行单元同时、并行被执行。而并发的执行单元对共享资源(硬件资源和软件上的全局、静态变量)的访问则容易导致竞态(race conditions)。可能导致并发和竟态的情况有： SMP（Symmetric Multi-Processing），对称多处理结构。SMP是一种紧耦合、共享存储的系统模型，它的特点是多个CPU使用共同的系统总线
在上一部分，我们讨论了最基本常见的几类同步机制，这一部分我们将讨论相对复杂的几种同步机制，尤其是读写信号量和RCU，在操作系统内核中有相当广泛的应用。
seqlock（顺序锁） 用于能够区分读与写的场合，并且是读操作很多、写操作很少，写操作的优先权大于读操作。 seqlock的实现思路是，用一个递增的整型数表示sequence。写操作进入临界区时，sequence++；退出临界区时，sequence再++。写操作还需要获得一个锁（比如mutex），这个锁仅用于写写互斥，以保证同一时间最多只有一个正在进行的写操作。 当sequence为奇数时，表示有写操作正在进行，这时读操作要进入临界区需要等待，直到sequence变为偶数。读操作进入临界区时，需要记录
（1）直接： 相互制约关系源于进程合作，表现为： 进程—进程 （同步：合作完成任务的关系！） 为完成同一个任务的诸进程间，因需要协调它们的工作而相互等待、相互交换信息所产生的直接制约关系。 这种制约主要源于进程间的合作。 发生在相关进程之间 eg:
在前面小节分析了spin_lock的实现，可以知道spin_lock只允许一个thread进入临界区，而且对进入临界区中的操作不做细分。但是在实际中，对临界区的操作分为读和写。如果按照spin_lock的实现，当多个read thread都想进入临界区读取的时候，这时候只有一个read thread进入到临界区，这样效率和性能明显下降。所以就针对某些操作read thread占绝大多数的情况下，提出了读写锁的概念。
初学者在使用 多线程 并发执行任务时一定会遇到 并发访问的问题，最直观的感受就是每次运行得出的结果值大概率不一致，这种执行结果不一致的现象是非常致命，因为它具有随机性，即结果可能是对的，也可能是错的，无法可靠的完成任务，类似物理学神兽 薛定谔的猫
不确定性和不可重现意味着bug可能是间歇性发生的 进程,线程;计算机,设备需要合作
上一篇文章 可见性有序性，Happens-before来搞定，解决了并发三大问题中的两个，今天我们就聊聊如何解决原子性问题
c#信号量Semaphore只允许有限数量的线程进入临界区。信号量主要用于资源有限，我们必须限制使用线程的数量的场景。
同步：同步方法一旦调用，那么调用该同步方法的线程必须等待这个同步方法执行完毕之后才可以继续执行后续的代码，后续的代码可以实时使用同步方法返回的数据。
虽然这个世界充满了不确定性，但是你可以用自己的超级确定性，来对冲外界的不确定。作为个体，我们貌似无力反抗，但是我们手里扣着一张王牌，就是技术。
关于线程安全的专有名词有一大堆。你们突然之间问我这个名词是什么意思，那个名词是什么意思我还真不一定能给你准确的回答。这还别说一门语言一堆名词。其实有些名词叫法不同，实际上就是一个意思。
最近在网上看到一些关于在DllMain中不当操作导致死锁的问题，也没找到比较确切的解答，这极大吸引了我研究这个问题的兴趣。我花了一点时间研究了下，正好也趁机研究了下进程对DllMain的调用规律。因为整个研究篇幅比较长，我觉得还是分开写比较能突出重点。本文先说说死锁。（转载请指明出于breaksoftware的csdn博客）
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
