信号量强调的是线程（或进程）间的同步：“信号量用在多线程多任务同步的，一个线程完成了某一个动作就通过信号量告诉别的线程，别的线程再进行某些动作（大家都在sem_wait的时候，就阻塞在那里）。当信号量为单值信号量时，也可以完成一个资源的互斥访问。信号量测重于访问者对资源的有序访问，在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源。
锁是一个常见的同步概念，我们都听说过加锁（lock）或者解锁（unlock），当然学术一点的说法是获取（acquire）和释放（release）。
进程在多数早期多任务操作系统中是执行工作的基本单元。进程是包含程序指令和相关资源的集合，每个进程和其他进程一起参与调度，竞争 CPU 、内存等系统资源。每次进程切换，都存在进程资源的保存和恢复动作，这称为上下文切换。进程的引入可以解决多用户支持的问题，但是多进程系统也在如下方面产生了新的问题：进程频繁切换引起的额外开销可能会严重影响系统性能。
文章主要介绍了在Linux系统中，如何利用自旋锁来实现线程之间的同步和互斥。主要包括了自旋锁的定义、工作原理、使用方式和注意事项，并通过实例介绍了如何在C语言中实现自旋锁。
很多时候，我们做项目并不会创建那么多进程，而是创建一个进程，在该进程中创建多个线程进行工作。
---- Hello、Hello大家好，我是木荣，今天我们继续来聊一聊Linux中多线程编程中的重要知识点，详细谈谈多线程中同步和互斥机制。 同步和互斥 互斥：多线程中互斥是指多个线程访问同一资源时同时只允许一个线程对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的； 同步：多线程同步是指在互斥的基础上（大多数情况），通过其它机制实现访问者对资源的有序访问。在大多数情况下，同步已经实现了互斥，特别是所有写入资源的情况必定是互斥的。少数情况是指可以允许多个访问者同时访问资源
相信需要了解这方面的知识的小伙伴，已经基本对进程间通信和线程间通信有了一定了解。例如，进程间通信的机制之一：共享内存（在这里不做详解）：多个进程可同时访问同一块内存。如果不对访问这块内存的临界区进行互斥或者同步，那么进程的运行很可能出现一些不可预知的错误和结果。
面试中经常会被问到高性能服务模型选择对比，以及如何提高服务性能和处理能力，这其中涉及操作系统软件和计算机硬件知识，其实都是在考察候选人的基础知识掌握程度，但如果没准备的话容易一头雾水，这次带大家从头到尾学习一遍，学完这一篇再也不怕面试官刨根问底了！
典型的UNIX系统都支持一个进程创建多个线程(thread)。在Linux进程基础中提到，Linux以进程为单位组织操作，Linux中的线程也都基于进程。尽管实现方式有异于其它的UNIX系统，但Linux的多线程在逻辑和使用上与真正的多线程并没有差别。 多线程 我们先来看一下什么是多线程。在Linux从程序到进程中，我们看到了一个程序在内存中的表示。这个程序的整个运行过程中，只有一个控制权的存在。当函数被调用的时候，该函数获得控制权，成为激活(active)函数，然后运行该函数中的指令。与此同时，其它的函数
某一资源同时只允许一个访问者对其进行访问，具有唯一性和排它性。但互斥无法限制访问者对资源的访问顺序，即访问是无序的，线程间不需要知道彼此的存在。
* UNIX进程间通信方式: 包括管道(PIPE), 有名管道(FIFO), 和信号(Signal)
操作系统（Operating System，简称OS）是计算机系统中的核心软件，它管理计算机硬件资源，提供程序运行的环境，并作为用户与计算机硬件之间的接口。操作系统的主要目标是提高计算效率，简化用户操作，并使计算机系统的使用更加方便和高效。
在多线程环境中，多个线程可能会同时访问同一个资源，为了避免访问发生冲突，可以根据访问的复杂程度采取不同的措施
在上一部分，我们讨论了最基本常见的几类同步机制，这一部分我们将讨论相对复杂的几种同步机制，尤其是读写信号量和RCU，在操作系统内核中有相当广泛的应用。
读写锁其实还是一种锁，是给一段临界区代码加锁，但是此加锁是在进行写操作的时候才会互斥，而在进行读的时候是可以共享的进行访问临界区的。 读写锁和互斥量（互斥锁）很类似，是另一种线程同步机制，但不属于POSIX标准，可以用来同步同一进程中的各个线程。当然如果一个读写锁存放在多个进程共享的某个内存区中，那么还可以用来进行进程间的同步，
现代操作系统基本都是多任务操作系统，即同时有大量可调度实体在运行。在多任务操作系统中，同时运行的多个任务可能：
用户空间(User Space) ：用户空间又包括用户的应用程序(User Applications)、C 库(C Library) 。
实时分为硬实时和软实时，硬实时要求绝对保证响应时间不超过期限，如果超过期限，会造成灾难性的后果，例如汽车在发生碰撞事故时必须快速展开安全气囊；软实时只需尽力使响应时间不超过期限，如果偶尔超过期限，不会造成灾难性的后果.
MMKV 是基于 mmap 内存映射的移动端通用 key-value 组件，底层序列化/反序列化使用 protobuf 实现，性能高，稳定性强。从 2015 年中至今，在 iOS 微信上使用已有近 3 年，其性能和稳定性经过了时间的验证。近期已移植到 Android 平台。在腾讯内部开源半年之后，得到公司内部团队的广泛应用和一致好评。现在一并对外开源： https://github.com/tencent/mmkv 欢迎 Star、提 Issue 和 PR。 前言 MMKV 的源起、设计原理与具体实现参
在Rust源代码中，rust/library/std/src/sys/unsupported/time.rs文件的作用是提供对于时间的支持，特别是在不支持的操作系统上。
在早期的 Linux内核中，并发的来源相对较少。早期内核不支持对称多处理（ symmetric multi processing,SMP），因此，导致并发执行的唯一原因是对硬件中断的服务。这种情况处理起来较为简单，但并不适用于为获得更好的性能而使用更多处理器且强调快速响应事件的系统。
前言 作为Node语言的初学者去实践后端开发时，不仅仅有见猎心喜，也有一些忐忑，好在大家都很open，给予了很多建议和分享，到目前为止，也成功建立了三个基于Node.js + TypeScript + IMServer 1 的工程，也是时候将自己最近的学习过程进行总结，下面就以一个小小的开发任务为载体分享下我的成长过程。 需求 在完成Node工程的搭建之后，我接受到第一个Node后台开发任务：定时将企业微信的组织架构信息拉取到业务数据库系统中，并且提供手机号查询用户查询接口。一开始对这个任务还是比较乐观的，
作为Node语言的初学者去实践后端开发时，不仅仅有见猎心喜，也有一些忐忑，好在大家都很open，给予了很多建议和分享，到目前为止，也成功建立了三个基于Node.js + TypeScript + IMServer 1 的工程，也是时候将自己最近的学习过程进行总结，下面就以一个小小的开发任务为载体分享下我的成长过程。
对于基础类型操作，使用原子变量就可以做到线程安全，那原子操作是如何保证线程安全的呢？linux中的原子变量如下：
一、顺序程序与并发程序特征 顺序程序特征 顺序性 封闭性：（运行环境的封闭性） 确定性 可再现性 并发程序特征 共享性 并发性 随机性 二、进程互斥 1、由于各进程要求共享资源，而且有些资源
我们知道，如今CPU的计算能力已经非常强大，其速度比内存要高出许多个数量级。为了充分利用CPU资源，多数编程语言都提供了并发编程的能力，Rust也不例外。
1 互斥锁 在线程实际运行过程中，我们经常需要多个线程保持同步。 这时可以用互斥锁来完成任务。互斥锁的使用过程中，主要有 pthread_mutex_init pthread_mutex_destory pthread_mutex_lock pthread_mutex_unlock 这几个函数以完成锁的初始化，锁的销毁，上锁和释放锁操作。 1.1 锁的创建 锁可以被动态或静态创建，可以用宏PTHREAD_MUTEX_INITIALIZER来静态的初始化锁，采用这种方式比较容易理解，互斥锁是pthread_m
对于进程来说，子进程是父进程的复制品，从父进程那里获得父进程的数据空间，堆和栈的复制品。
既然是锁CPU，那就都是针对多核处理器或多CPU处理器。单核的话，只有发生中断会使任务被抢占，那么可以进入临界区之前先关中断，但是对多核CPU光关中断就不够了，因为对当前CPU关了中断只能使得当前CPU不会运行其它要进入临界区的程序，但其它CPU还是可能执行进入临界区的程序。
* 读优先：读任务占有锁时，后续的读任务可以立即获得锁；这种设计可以提高并发性能（后来的读任务不需要等待），但如果读任务太多，会造成写任务一直处于等待中，造成写饥饿现象
Linux 内核有非常多的锁机制，如：自旋锁、读写锁、信号量和 RCU 锁等。本文介绍一种和读写锁比较相似的锁机制：顺序锁（seqlock）。
不是什么时候都要靠上锁的。从根源出发，我们为什么需要上锁？因为线程在使用资源的过程中可能会出现冲突，对于这种会出现冲突的资源，还是锁住轮着用比较好。
管道一般为有亲缘关系进程提供单路数据流， 通过pipe（int fd[2]）创建， 返回两个文件描述符, fd[0] 用于读，fd[1]用于写。 通过 read 和 write 函数进行 操作。
内核死锁问题一般是读写锁(rw_semaphore)和互斥锁(mutex)引起的，本文主要讲如何通过ramdump+crash工具来分析这类死锁问题。
什么是多线程，提出这个问题的时候，我还是很老实的拿出操作系统的书，按着上面的话敲下“为了减少进程切换和创建开销，提高执行效率和节省资源，我们引入了线程的概念，与进程相比较，线程是CPU调度的一个基本单位。”
在分布式系统中，当多个线程（或进程）同时操作同一个资源时，为了保证数据一致性问题，所以就需要一种机制来确保在同一时间只有一个线程（或进程）能够对资源进行修改，这就是分布式锁的作用。
ACE (Adaptive Communication Environment) 是早年间很火的一个 c++ 开源通讯框架，当时 c++ 的库比较少，以至于谈 c++ 网络通讯就绕不开 ACE，随着后来 boost::asio / libevent / libev … 等专门解决通讯框架的库像雨后春笋一样冒出来，ACE 就渐渐式微了。特别是它虽然号称是通讯框架，实则把各个平台的基础设施都封装了一个遍，导致想用其中一个部分，也牵一发而动全身的引入了一堆其它的不相关的部分，虽然用起来很爽，但是耦合度太强，学习曲线过于陡峭，以至于坊间流传一种说法：ACE 适合学习，不适合快速上手做项目。所以后来也就慢慢淡出了人们的视线，不过对于一个真的把它拿来学习的人来说，它的一些设计思想还是不错的，今天就以线程同步对象为例，说一下“史上最全”的 ACE 是怎么封装的，感兴趣的同学可以和标准库、boost 或任意什么跨平台库做个对比，看看它是否当得起这个称呼。
之前我们说过线程安全问题可以用锁机制来解决，即线程必要要先获得锁，之后才能进行其他操作。其实在 Java 的 API 中有这样一些锁类可以提供给我们使用，与其他对象作为锁相比，它们具有更强大的功能。 Java 中的锁有两种，分别是：1）同步锁 2）读写锁 一、同步锁 同步锁（ReentrantLock）类似于 synchronize 代码块中传入的那个锁对象，可以用于进行线程同步。ReentrantLock.lock() 方法用于锁定对象，而 ReentrantLock.unlock 用于释放锁对象。
答：i++不是原子操作，++i也不是原子操作。 原子操作是指不会被线程调度机制打断的操作；这种操作一旦开始，就一直运行到结束，中间不会切换到另一个线程。 i++其实一共做了三次指令操作，第一次，从内存中读取i变量的值到CPU的寄存器，第二次在寄存器中的i自增1，第三次将寄存器中的值写入内存。这三次指令操作中任意两次如果同时执行的话，都会造成结果的差异性。 而对于++i，在多核机器上，CPU在读取内存时也可能同时读到同一个值，这样就会同一个值自增两次，而实际上只自增了一次，所以++i也不是原子操作。
如果程序直接引用物理地址，可能导致内存只能使用一个程序。因为其他程序也运行的话，可能会直接占用前一个程序的物理地址。
艾伦在一次粒子加速器爆炸大事故中获得了极速移动的超能力，因此开始化身为超级英雄“闪电侠”。类比之下，CPU是计算机最核心的部件，它负责指令的读取和执行，每秒可以执行几十亿条指令！其实比闪电侠还要快得多。
进程是操作系统进行资源分配的基本单位，每个进程都有自己的独立内存空间。由于进程比较重量，占据独立的内存，所以上下文进程间的切换开销（栈、寄存器、虚拟内存、文件句柄等）比较大，但相对比较稳定安全。
在前面小节分析了spin_lock的实现，可以知道spin_lock只允许一个thread进入临界区，而且对进入临界区中的操作不做细分。但是在实际中，对临界区的操作分为读和写。如果按照spin_lock的实现，当多个read thread都想进入临界区读取的时候，这时候只有一个read thread进入到临界区，这样效率和性能明显下降。所以就针对某些操作read thread占绝大多数的情况下，提出了读写锁的概念。
https://segmentfault.com/a/1190000010895869
最近在学习 Zookeeper，在刚开始接触 Zookeeper 的时候，完全不知道 Zookeeper 有什么用。且很多资料都是将 Zookeeper 描述成一个“类 Unix/Linux 文件系统”的中间件，导致我很难将类 Unix/Linux 文件系统的 Zookeeper 和分布式应用联系在一起。后来在粗读了《ZooKeeper 分布式过程协同技术详解》和《从Paxos到Zookeeper 分布式一致性原理与实践》两本书，并动手写了一些 CURD demo 后，初步对 Zookeeper 有了一定的了解。不过比较肤浅，为了进一步加深对 Zookeeper 的认识，我利用空闲时间编写了本篇文章对应的 demo – 基于 Zookeeper 的分布式锁实现。通过编写这个分布式锁 demo，使我对 Zookeeper 的 watcher 机制、Zookeeper 的用途等有了更进一步的认识。不过我所编写的分布式锁还是比较简陋的，实现的也不够优美，仅仅是个练习，仅供参考使用。好了，题外话就说到这里，接下来我们就来聊聊基于 Zookeeper 的分布式锁实现。
桔妹导读：死锁是多线程和分布式程序中常见的一种严重问题。死锁是毁灭性的，一旦发生，系统很难或者几乎不可能恢复；死锁是随机的，只有满足特定条件才会发生，而如果条件复杂，虽然发生概率很低，但是一旦发生就非常难重现和调试。使用锁而产生的死锁是死锁中的一种常见情况。Linux 内核使用 Lockdep 工具来检测和特别是预测锁的死锁场景。然而，目前 Lockdep 只支持处理互斥锁，不支持更为复杂的读写锁，尤其是递归读锁（Recursive-read lock）。因此，Lockdep 既会出现由读写锁引起的假阳性预测错误，也会出现假阴性预测错误。
这几天在做 学生考试系统，其中需要存储数据时要并发，然而我采用的sqlite3,小型数据库，导致了很多问题，特别是在多进程访问写的时候，特此分享给大家；
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
