对比两脚本的执行结果，lock-free是明显优于spin-lock的。接着从程序代码的差异上分析，lock-free在一条语句上（atomic_compare_exchange_weak(&count, &val, val+1)）完成了修改，而spin-lock则是“持有锁》修改值〉释放锁”。它们之间的差异可以由下两图体现：
非阻塞无锁(Lock-Free)算法用底层的机器指令（例如比较交换-CAS指令）代替锁来确保数据在并发访问中的一致性。
多线程编程是多CPU系统在中应用最广泛的一种编程方式，在传统的多线程编程中，多线程之间一般用各种锁的机制来保证正确的对共享资源（share resources）进行访问和操作。
也就常说的单生产者-单消费者 的ringbuffer， 限制就是只能一个读线程（消费者），一个写进程（生产者）。
无锁编程，即不使用锁的情况下实现多线程之间的变量同步，也就是在没有线程被阻塞的情况下实现变量的同步，所以也叫非阻塞同步（Non-blocking Synchronization）。
RCU是Linux 2.6内核系统新的锁机制 RCU(Read-Copy Update)。参考：http://www.ibm.com/developerworks/cn/linux/l-rcu/
在我们的工作中，多线程编程是一件太稀松平常的事。在多线程环境下操作一个变量或者一块缓存，如果不对其操作加以限制，轻则变量值或者缓存内容不符合预期，重则会产生异常，导致进程崩溃。为了解决这个问题，操作系统提供了锁、信号量以及条件变量等几种线程同步机制供我们使用。如果每次操作都使用上述机制，在某些条件下(系统调用在很多情况下不会陷入内核)，系统调用会陷入内核从而导致上下文切换，这样就会对我们的程序性能造成影响。
阻塞同步有许多实现方式了：mutex, semaphore. 阻塞同步使用不当就可能造成死锁，活锁，优先级反转。
It's error-prone and requires expert level knowledge of language features, machine architecture, and data structures.
Boost_1_53_0终于迎来了久违的Boost.Lockfree模块，本着学习的心态，将其翻译如下。（原文地址：http://www.boost.org/doc/libs/1_53_0/doc/html/lockfree.html）
SSE2 extensions introduce two new fence instructions (LFENCE and MFENCE) as companions to the SFENCE instruction introduced with SSE extensions. The LFENCE instruction establishes a memory fence for loads. It guarantees ordering between two loads and prevents speculative loads from passing the load fence (that is, no speculative loads are allowed until all loads specified before the load fence have been carried out). The MFENCE instruction establishes a memory fence for both loads and stores. The processor ensures that no load or store after MFENCE will become globally visible until all loads and stores before MFENCE are globally visible.1 Note that the sequences LFENCE;SFENCE and SFENCE;LFENCE are not equivalent to MFENCE because neither ensures that older stores are globally observed prior to younger loads.
CAS 一般采用原子级的read-modify-write原语来实现Lock-Free算法，其中LL和SC是Lock-Free理论研究领域的理想原语，但实现这些原语需要CPU指令的支持，非常遗憾的是目前没有任何CPU直接实现了SC原语。根据此理论，业界在原子操作的基础上提出了著名的CAS（Compare-And-Swap）操作来实现Lock-Free算法，Intel实现了一条类似该操作的指令：cmpxchg8。 CAS原语负责将某处内存地址的值（1个字节）与一个期望值进行比较，如果相等，则将该内存地址处的值
1. 简介 Metadata Lock，顾名思义，是对元数据的保护。MDL 是在 5.5 中引入的，之前版本对于元数据也有保护，但实现为语句级别的，当语句结束后元数据相关的锁就会被释放掉。这种实现会导致两个主要的问题： 无法实现 RR 隔离级别，比如以下场景： tx1: BEGIN;tx1: SELECT * FROM tbl; -- 获取元数据锁，返回(c1,c2)，释放元数据锁tx2: ALTER TABLE tbl DROP COLUMN c2; -- 获取元数据锁，成功，释放元数据锁tx1: SEL
本文介绍了MDL子系统的设计和实现细节，包括锁获取与释放，死锁检测，以及使用到的相关lock-free优化。
现如今，一个服务端应用程序几乎都会使用到多线程来提升服务性能，而目前服务端还是以linux系统为主。一个多线程的java应用，不管使用了什么样的同步机制，最终都要用JVM执行同步处理，而JVM本身也是linux上的一个进程，那么java应用的线程同步机制，可以说是对操作系统层面的同步机制的上层封装。这里我说的操作系统，主要是的非实时抢占式内核（non-PREEMPT_RT），并不讨论实时抢占式内核（PREEMPT_RT） 的问题，二者由于使用场景不同，因此同步机制也会存在差异或出现变化。
Oracle Database 23ai支持Lock-Free Reservation，中文通常译为“无锁列值保留”。
lock free (中文一般叫“无锁”，一般指的都是基于CAS指令的无锁技术) 是利用处理器的一些特殊的原子指令来避免传统并行设计中对锁(lock)的使用。
关于无锁队列的实现，网上有很多文章，虽然本文可能和那些文章有所重复，但是我还是想以我自己的方式把这些文章中的重要的知识点串起来和大家讲一讲这个技术。下面开始正文。
活锁、死锁本质上是一样的，原因是在获取临界区资源时，并发多个进程/线程声明资源占用(加锁)的顺序不一致，死锁是加不上就死等，活锁是加不上就放开已获得的资源重试，其实单机场景活锁不太常见。举个例子资源A和B，进程P1和P2，
1 互斥锁 在线程实际运行过程中，我们经常需要多个线程保持同步。 这时可以用互斥锁来完成任务。互斥锁的使用过程中，主要有 pthread_mutex_init pthread_mutex_destory pthread_mutex_lock pthread_mutex_unlock 这几个函数以完成锁的初始化，锁的销毁，上锁和释放锁操作。 1.1 锁的创建 锁可以被动态或静态创建，可以用宏PTHREAD_MUTEX_INITIALIZER来静态的初始化锁，采用这种方式比较容易理解，互斥锁是pthread_m
(1)队列的大小（m_lMaxQueueSize）应该足够的大，避免处理不过来时，找半天找不到空位置。
概念 忙等待可以认为是一种特殊的忙等待 忙等待分类 Peterson算法 xchg解法 TSL解法 自旋锁 Peterson算法 Peterson算法是一个实现互斥锁的并发程序设计算法，可以控制两个线程访问一个共享的单用户资源而不发生访问冲突。GaryL. Peterson于1981年提出此算法。 #include <stdio.h> #include <pthread.h> #include <stdlib.h> #include <sys/types.h> #include <sys/time.h> #
我们知道在Java多线程里面关于共享变量的操作，一定是要使用线程同步来保证线程安全的，一旦涉及线程同步，就需要加锁，一旦加锁就意味着某一个时候只能有一个线程在操作，其他的线程如果没有得到锁就会阻塞起来，此时的线程的状态是BLOCKED，当前面的线程释放锁的时候，系统会自动调度当前的线程进入临界区，这里面存在一个问题，就是线程的上下文切换的问题，虽然比起来进程的上下文切换，线程的上下文切换更轻量级，但仍然也是有一定开销的，比如最简单的i++的例子，那么如何有没有一种不需要加锁也能保证线程安全的数据结构呢？答案是肯定的，这就是今天需要谈到的CAS（Compare And Swap或 Compare And Set）。
github.com/rs/zerolog@v1.20.0/diode/diode.go
sychronized 是Java语法层面的同步策略，可以用来修饰instance变量、object reference（对象引用）、static函数和class literals(类名称字面常量)。 1、当非static 元素被sychronized修饰时，当前线程都会取得该对象锁，该对象的其他线程均无法访问任何被sychronized修饰的变量或方法。即一个类如果有n个方法被sychronized修饰时，a线程取得对象锁之后，其他线程除a线程正在使用的方法无法使用外，其他需要对象锁的方法均无法使用。即一个对象仅有一个对象锁，一个线程取得后，其他线程都无法获得，其他线程都要阻塞。 2、不同的对象实例的 synchronized方法是不相干扰的。 3、当static 元素被sychronize修饰时，可以防止多个线程同时访问这个类中的synchronized static 方法。它可以对类的所有对象实例起作用。 注意：synchronized都是会阻塞线程的，就是说会发生上下文切换，从用户态切换到内核态，所以由sychronized实现对象锁代价较高（新的JDK版本已经优化的较好，但这种方式代价仍然不小），并且使用sychronized涉及对象锁如果在两个以上很容易造成死锁，谨慎使用同步策略，避免无谓的取锁。 很显然sychronized是一种独占锁，也就是悲观锁，默认一定会发生资源争用，所以每次都默认取锁。
有一个很多人也许都不是很清楚的问题：i++或++i是一个原子操作吗？在上一节，其实已经提到了，在SMP（对称多处理器）上，即使是单条递减汇编指令，其原子性也是不能保证的。那么在单处理机系统中呢？
近期看一些源码，会有一些注释是LockFree。这到底啥玩意儿？之前我也不知道啊，遂赶紧上网查之，总结了一些东西作为记录，与大家分享。
这是 <<Crust of Rust>> 作者的最新的一期视频, 这一期视频中, 作者使用 Rust 实现了并发算法论文 <>.
Michael Barker edited this page on 2 Mar 2015 · 8 revisions
1. 引言 现代计算机，即使很小的智能机亦或者平板电脑，都是一个多核(多CPU)处理设备，如何充分利用多核CPU资源，以达到单机性能的极大化成为我们码农进行软件开发的痛点和难点。在多核服务器中，采用多进程或多线程来并行处理任务，俨然成为了大家性能调优的标准解决方案。多进程(多线程)的并行编程方式，必然要面对共享数据的访问问题，如何并发、高效、安全地访问共享数据资源，成为并行编程的一个重点和难点。 传统的共享数据访问方式是采用同步原语(临界区、锁、条件变量等)来达到共享数据的安全访问，然而，同步恰恰和
国人开发。实现了 embedded, in-memory, zero-copy, ACID, MVCC, almost lock-free and serializable snapshot isolation 等特性。
LockFree的基础知识涉及：Atomic（原子操作），CAS（Compay and swap），内存预分配；
Double-checked locking is easy to mess up. If you really need to write your own double-checked locking, in spite of the rules CP.110: Do not write your own double-checked locking for initialization and CP.100: Don't use lock-free programming unless you absolutely have to, then do it in a conventional pattern.
synrhronized关键字简洁、清晰、语义明确，因此即使有了Lock接口，使用的还是非常广泛。其应用层的语义是可以把任何一个非null对象作为"锁"，当synchronized作用在方法上时，锁住的便是对象实例（this）；当作用在静态方法时锁住的便是对象对应的Class实例，因为Class数据存在于永久带，因此静态方法锁相当于该类的一个全局锁；当synchronized作用于某一个对象实例时，锁住的便是对应的代码块。在HotSpot JVM实现中，锁有个专门的名字：对象监视器。
什么是原子操作 原子操作可以保证指令以原子的方式执行——执行过程不被打断，原子操作是多数无锁编程的基本前提。 原子操作分为以下几类 对1字节的读写 对2字节数（对齐到16位边界）读写 对4字节数（对齐到32位边界）读写 对8字节数（对齐到64位边界）读写 xchg 原子操作基本原理 在x86平台上，CPU提供了在指令执行期间对总线加锁的手段。CPU芯片上有一条引线#HLOCK pin，如果汇编语言的程序中在一条指令前面加上前缀"LOCK"，经过汇编以后的机器代码就使CPU在执行这条指令的时候把#HLOCK
Linux kernel 的 kretprobe 机制和 kprobe 完全不同，本质原因在于，函数的入口地址是固定的，但函数的返回地址不固定，由于返回位置不固定，无法固定函数大小，无法事先插桩。一图以示之:
在ARM平台上，ARMv6之前，SWP和SWPB指令被用来支持对shared memory的访问：
简介 WiredTiger是什么 WT引擎是一个高性能、可扩展、支持事务、可以用于生产的的NoSQL数据引擎 WT能够处理超过当前节点内存容量的数据集合，但是不会影响性能下降,具有低延迟和高吞吐特性 WT提供非阻塞的全事务能力,支持PB级别的表 WT引擎设置遵循的原则 WT在CPU多核下扩展性较好，采用lock-free、fast latching、message passing的编程模型 Hot Caches WT支持面向row-oriented 和column-oriented 的存储模式，colu
现在市面上很少有关于Unsafe的话题。这个Unsafe有个compareAndSwap方法是原子的，并且使用这个方法可以实现高性能的lock-free的数据结构。 现在我们假设一个场景，多个线程试
无锁编程是指在不使用锁的情况下，在多线程环境下实现多变量的同步。即在没有线程阻塞的情况下实现同步。这样可以避免竞态、死锁等问题。
并发编程的源头是在于内存中的数据需要在不同的线程之间共享, 因为多线程程序在运行时存在交错(interleaving).
RCU（Read-Copy Update） RCU就是指读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读操作不需要获得任何锁就可以访问，但写操作在访问它时首先拷贝一个副本，然后对副本进行修改，最后在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。 Linux内核中内存管理大量的运用到了RCU机制。为每个内存对象增加了一个原子计数器用来继续该对象当前访问数。当没有其他进程在访问该对象时（计数器为0），才允许回收该内存。 从
本文内容译自Lock-freedom without garbage collection,中间有少量自己的修改.
在 .NET 4.0 之前，如果我们需要在多线程环境下使用 Dictionary 类，除了自己实现线程同步来保证线程安全之外，我们没有其他选择。 很多开发人员肯定都实现过类似的线程安全方案，可能是通过创建全新的线程安全的字典类型，或者仅是简单的用一个类封装一个 Dictionary 对象，并在所有方法中加上锁机制，我们称这种方案叫“Dictionary + Locks”。 但现在，我们有了 ConcurrentDictionary。在 MSDN 中的 Dictionary 类文档的线程安全的描述中指出，如果
最近群里聊起秒杀和限流，我自己没有做过类似应用，但是工作中遇到过更大的数据和并发。 于是提出了一个简单的模型： var count = rds.inc(key); if(count > 1000) throw "已抢光！" 借助Redis单线程模型，它的inc是安全的，确保每次加一，然后返回加一后的结果。如果原来是234，加一了就是235，返回的一定是235，在此中间，不会有别的请求来打断从而导致返回236或者其它。 其实我们可以理解为inc的业务就是占坑排队，每人占一个坑，拿到排队小票后看看是不是超额了，
临界区表示被多个线程使用的公共资源，但是每一次只能有一个线程使用它。 比如打印机资源。
disruptor是LAMX用于交易场景的一个环形队列。按照disruptor的官方wiki中说的，学习disruptor的最好的方式就是与java中的BlockingQueue进行比较。在disruptor中同一个进程中的线程间数据的移动是依托于 messages或者events。和queue相同的一些关键特性中，disruptor提供了更好的实现，比如：
从reddit/hackernews/lobsters/meetingcpp摘抄一些c++动态
那么在io事件中，g是怎么把事件交还给g0的呢？这时候就牵扯到我们今天的主角----netpoll。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
