Optimistic concurrency control

https://en.wikipedia.org/wiki/Optimistic_concurrency_control

Optimistic concurrency control (OCC) is a concurrency control method applied to transactional systems such as relational database management systems and software transactional memory. OCC assumes that multiple transactions can frequently complete without interfering with each other. While running, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the data it has read. If the check reveals conflicting modifications, the committing transaction rolls back and can be restarted.^[1] Optimistic concurrency control was first proposed by H.T. Kung.^[2]

【无锁，事务不等待】

OCC is generally used in environments with low data contention. When conflicts are rare, transactions can complete without the expense of managing locks and without having transactions wait for other transactions' locks to clear, leading to higher throughput than other concurrency control methods. However, if contention for data resources is frequent, the cost of repeatedly restarting transactions hurts performance significantly; it is commonly thought^[who?] that other concurrency control methods have better performance under these conditions.^{[citation needed]} However, locking-based ("pessimistic") methods also can deliver poor performance because locking can drastically limit effective concurrency even when deadlocks are avoided.

https://www.ibm.com/support/knowledgecenter/en/SSPK3V_7.0.0/com.ibm.swg.im.soliddb.sql.doc/doc/pessimistic.vs.optimistic.concurrency.control.html

Pessimistic concurrency control (or pessimistic locking) is called "pessimistic" because the system assumes the worst — it assumes that two or more users will want to update the same record at the same time, and then prevents that possibility by locking the record, no matter how unlikely conflicts actually are.

The locks are placed as soon as any piece of the row is accessed, making it impossible for two or more users to update the row at the same time. Depending on the lock mode (shared, exclusive, or update), other users might be able to read the data even though a lock has been placed. For more details on the lock modes, see Lock modes: shared, exclusive, and update.
Optimistic concurrency control (or optimistic locking) assumes that although conflicts are possible, they will be very rare. Instead of locking every record every time that it is used, the system merely looks for indications that two users actually did try to update the same record at the same time. If that evidence is found, then one user's updates are discarded and the user is informed.
For example, if User1 updates a record and User2 only wants to read it, then User2 simply reads whatever data is on the disk and then proceeds, without checking whether the data is locked. User2 might see slightly out-of-date information if User1 has read the data and updated it, but has not yet committed the transaction.

Optimistic locking is available on disk-based tables (D-tables) only.

https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/TransactionJTA_Overview-Pessimistic_and_optimistic_locking.html

6.1.1. Pessimistic and optimistic locking

Transactional isolation is usually implemented by locking whatever is accessed in a transaction. There are two different approaches to transactional locking: Pessimistic locking and optimistic locking.

The disadvantage of pessimistic locking is that a resource is locked from the time it is first accessed in a transaction until the transaction is finished, making it inaccessible to other transactions during that time. If most transactions simply look at the resource and never change it, an exclusive lock may be overkill as it may cause lock contention, and optimistic locking may be a better approach. With pessimistic locking, locks are applied in a fail-safe way. In the banking application example, an account is locked as soon as it is accessed in a transaction. Attempts to use the account in other transactions while it is locked will either result in the other process being delayed until the account lock is released, or that the process transaction will be rolled back. The lock exists until the transaction has either been committed or rolled back.

With optimistic locking, a resource is not actually locked when it is first is accessed by a transaction. Instead, the state of the resource at the time when it would have been locked with the pessimistic locking approach is saved. Other transactions are able to concurrently access to the resource and the possibility of conflicting changes is possible. At commit time, when the resource is about to be updated in persistent storage, the state of the resource is read from storage again and compared to the state that was saved when the resource was first accessed in the transaction. If the two states differ, a conflicting update was made, and the transaction will be rolled back.

In the banking application example, the amount of an account is saved when the account is first accessed in a transaction. If the transaction changes the account amount, the amount is read from the store again just before the amount is about to be updated. If the amount has changed since the transaction began, the transaction will fail itself, otherwise the new amount is written to persistent storage.

【事务独立:通过对资源加锁实现】

事务锁：
悲观锁：因A事务对某资源加锁后，其他事务无法访问该资源，直到该事务访问结束而锁被释放
乐观锁：因A事务对某资源加锁后，其他事务可以访问该资源；但数据更新时候，如果两事务对数据的更新冲突，则发生数据回滚，资源不被任何一个事务修改；如果不同事务对资源的更新一致，则资源被更新。

https://baike.baidu.com/item/乐观锁

乐观锁机制采取了更加宽松的加锁机制。相对悲观锁而言，乐观锁更倾向于开发运用。

中文名: 乐观锁
外文名: Optimistic locking

介绍: 记录机制
应用: 金融行业

乐观锁介绍

乐观锁（ Optimistic Locking ）相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。而乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ Version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。

示例

如一个金融系统，当某个操作员读取用户的数据，并在读出的用户数据的基础上进行修改时（如更改用户帐户余额），如果采用悲观锁机制，也就意味着整个操作过程中（从操作员读出数据、开始修改直至提交修改结果的全过程，甚至还包括操作员中途去煮咖啡的时间），数据库记录始终处于加锁状态，可以想见，如果面对几百上千个并发，这样的情况将导致怎样的后果。

乐观锁机制在一定程度上解决了这个问题。乐观锁，大多是基于数据版本（ version ）记录机制实现。何谓数据版本？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。

读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。同时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号等于数据库表当前版本号，则予以更新，否则认为是过期数据。

对于上面修改用户帐户信息的例子而言，假设数据库中帐户信息表中有一个 version 字段，当前值为 1 ；而当前帐户余额字段（ balance ）为 $100 。

1 操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。

2 在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。

3 操作员 A 完成了修改工作，将 version=1 的数据连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本等于数据库记录当前版本，数据被更新，同时数据库记录 version 更新为 2（set version=version+1 where version=1）。

4 操作员 B 完成了数据录入操作，也将 version=1 的数据试图向数据库提交（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 1 ，数据库记录当前版本也为 2 ，不满足 “ 提交版本必须等于记录当前版本才能执行更新 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。

这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

优点

从上面的例子可以看出，乐观锁机制避免了长事务中的数据库加锁开销（操作员 A和操作员 B 操作过程中，都没有对数据库数据加锁），大大提升了大并发量下的系统整体性能表现。

缺点

需要注意的是，乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的用户余额更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。

实现

编辑

Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用 Hibernate 提供的透明化乐观锁实现，将大大提升我们的生产力。

Hibernate 中可以通过 class 描述符的 optimistic-lock 属性结合 version

描述符指定。

现在，我们为之前示例中的 TUser 加上乐观锁机制。

添加属性

首先为 TUser 的 class 描述符添加 optimistic-lock 属性：

<hibernate-mapping>

<class

name="org.hibernate.sample.TUser"

table="t_user"

dynamic-update="true"

dynamic-insert="true"

optimistic-lock="version"

……

</class>

</hibernate-mapping>

optimistic-lock 属性有如下可选取值：

Ø none

无乐观锁

Ø version

通过版本机制实现乐观锁

Ø dirty

通过检查发生变动过的属性实现乐观锁

Ø all

通过检查所有属性实现乐观锁

其中通过 version 实现的乐观锁机制是 Hibernate 官方推荐的乐观锁实现，同时也

是 Hibernate 中，目前唯一在数据对象脱离 Session 发生修改的情况下依然有效的锁机

制。因此，一般情况下，我们都选择 version 方式作为 Hibernate 乐观锁实现机制。

添加描述符

添加一个 Version 属性描述符

<hibernate-mapping>

<class

name="org.hibernate.sample.TUser"

table="t_user"

dynamic-update="true"

dynamic-insert="true"

optimistic-lock="version"

<id

name="id"

column="id"

type="java.lang.Integer"

</generator>

</id>

<version

column="version"

name="version"

type="java.lang.Integer"

……

</class>

</hibernate-mapping>

注意 version 节点必须出现在 ID 节点之后。

这里我们声明了一个 version 属性，用于存放用户的版本信息，保存在 TUser 表的version 字段中。

此时如果我们尝试编写一段代码，更新 TUser 表中记录数据，如：

Criteria criteria = session.createCriteria(TUser.class);

criteria.add(Expression.eq("name","Erica"));

List userList = criteria.list();

TUser user =(TUser)userList.get(0);

Transaction tx = session.beginTransaction();

user.setUserType(1); // 更新 UserType 字段

tx.commit();

每次对 TUser 进行更新的时候，我们可以发现，数据库中的 version 都在递增。而如果我们尝试在 tx.commit 之前，启动另外一个 Session ，对名为 Erica 的用户进行操作，以模拟并发更新时的情形：

Session session= getSession();

Criteria criteria = session.createCriteria(TUser.class);

criteria.add(Expression.eq("name","Erica"));

Session session2 = getSession();

Criteria criteria2 = session2.createCriteria(TUser.class);

criteria2.add(Expression.eq("name","Erica"));

List userList = criteria.list();

List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);

TUser user2 =(TUser)userList2.get(0);

Transaction tx = session.beginTransaction();

Transaction tx2 = session2.beginTransaction();

user2.setUserType(99);

tx2.commit();

user.setUserType(1);

tx.commit();

执行以上代码，代码将在 tx.commit() 处抛出 StaleObjectStateException 异常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我们就可以在乐观锁校验失败时进行相应处理。

https://zh.wikipedia.org/wiki/自旋锁

自旋锁是计算机科学用于多线程同步的一种锁，线程反复检查锁变量是否可用。由于线程在这一过程中保持执行，因此是一种忙等待。一旦获取了自旋锁，线程会一直保持该锁，直至显式释放自旋锁。

自旋锁避免了进程上下文的调度开销，因此对于线程只会阻塞很短时间的场合是有效的。因此操作系统的实现在很多地方往往用自旋锁。Windows操作系统提供的轻型读写锁（SRW Lock）内部就用了自旋锁。显然，单核CPU不适于使用自旋锁，这里的单核CPU指的是单核单线程的CPU，因为，在同一时间只有一个线程是处在运行状态，假设运行线程A发现无法获取锁，只能等待解锁，但因为A自身不挂起，所以那个持有锁的线程B没有办法进入运行状态，只能等到操作系统分给A的时间片用完，才能有机会被调度。这种情况下使用自旋锁的代价很高。

获取、释放自旋锁，实际上是读写自旋锁的存储内存或寄存器。因此这种读写操作必须是原子的。通常用test-and-set等原子操作来实现。^[1]

Windows内核API[编辑]

KeInitializeSpinLock //初始化自旋锁
KeAcquireSpinLock //获取自旋锁
KeReleaseSpinLock //释放自旋锁

https://en.wikipedia.org/wiki/Spinlock

In software engineering, a spinlock is a lock which causes a thread trying to acquire it to simply wait in a loop ("spin") while repeatedly checking if the lock is available. Since the thread remains active but is not performing a useful task, the use of such a lock is a kind of busy waiting. Once acquired, spinlocks will usually be held until they are explicitly released, although in some implementations they may be automatically released if the thread being waited on (the one which holds the lock) blocks, or "goes to sleep".

Because they avoid overhead from operating system process rescheduling or context switching, spinlocks are efficient if threads are likely to be blocked for only short periods. For this reason, operating-system kernels often use spinlocks. However, spinlocks become wasteful if held for longer durations, as they may prevent other threads from running and require rescheduling. The longer a thread holds a lock, the greater the risk that the thread will be interrupted by the OS scheduler while holding the lock. If this happens, other threads will be left "spinning" (repeatedly trying to acquire the lock), while the thread holding the lock is not making progress towards releasing it. The result is an indefinite postponement until the thread holding the lock can finish and release it. This is especially true on a single-processor system, where each waiting thread of the same priority is likely to waste its quantum (allocated time where a thread can run) spinning until the thread that holds the lock is finally finished.

Implementing spin locks correctly offers challenges because programmers must take into account the possibility of simultaneous access to the lock, which could cause race conditions. Generally, such an implementation is possible only with special assembly-language instructions, such as atomic test-and-set operations and cannot be easily implemented in programming languages not supporting truly atomic operations.^[1] On architectures without such operations, or if high-level language implementation is required, a non-atomic locking algorithm may be used, e.g. Peterson's algorithm. However, such an implementation may require more memory than a spinlock, be slower to allow progress after unlocking, and may not be implementable in a high-level language if out-of-order execution is allowed.

Example implementation[edit]

The following example uses x86 assembly language to implement a spinlock. It will work on any Intel 80386 compatible processor.

; Intel syntax

locked:                      ; The lock variable. 1 = locked, 0 = unlocked.

     dd      0

spin_lock:

     mov     eax, 1          ; Set the EAX register to 1.

     xchg    eax, [locked]   ; Atomically swap the EAX register with

                             ;  the lock variable.

                             ; This will always store 1 to the lock, leaving

                             ;  the previous value in the EAX register.

     test    eax, eax        ; Test EAX with itself. Among other things, this will

                             ;  set the processor's Zero Flag if EAX is 0.

                             ; If EAX is 0, then the lock was unlocked and

                             ;  we just locked it.

                             ; Otherwise, EAX is 1 and we didn't acquire the lock.

     jnz     spin_lock       ; Jump back to the MOV instruction if the Zero Flag is

                             ;  not set; the lock was previously locked, and so

                             ; we need to spin until it becomes unlocked.

     ret                     ; The lock has been acquired, return to the calling

                             ;  function.

spin_unlock:

     xor     eax, eax        ; Set the EAX register to 0.

     xchg    eax, [locked]   ; Atomically swap the EAX register with

                             ;  the lock variable.

     ret                     ; The lock has been released.

Significant optimizations[edit]

The simple implementation above works on all CPUs using the x86 architecture. However, a number of performance optimizations are possible:

On later implementations of the x86 architecture, spin_unlock can safely use an unlocked MOV instead of the slower locked XCHG. This is due to subtle memory ordering rules which support this, even though MOV is not a full memory barrier. However, some processors (some Cyrix processors, some revisions of the Intel Pentium Pro (due to bugs), and earlier Pentium and i486 SMP systems) will do the wrong thing and data protected by the lock could be corrupted. On most non-x86 architectures, explicit memory barrier or atomic instructions (as in the example) must be used. On some systems, such as IA-64, there are special "unlock" instructions which provide the needed memory ordering.

To reduce inter-CPU bus traffic, code trying to acquire a lock should loop reading without trying to write anything until it reads a changed value. Because of MESI caching protocols, this causes the cache line for the lock to become "Shared"; then there is remarkably no bus traffic while a CPU waits for the lock. This optimization is effective on all CPU architectures that have a cache per CPU, because MESI is so widespread. On Hyper-Threading CPUs, pausing with rep nop gives additional performance by hinting the core that it can work on the other thread while the lock spins waiting.^[2]

Transactional Synchronization Extensions and other hardware transactional memory instruction sets serve to replace locks in most cases. Although locks are still required as a fallback, they have the potential to greatly improve performance by having the processor handle entire blocks of atomic operations. This feature is built into some mutex implementations, for example in glibc. The Hardware Lock Elision (HLE) in x86 is a weakened but backwards-compatible version of TSE, and we can use it here for locking without losing any compatibility. In this particular case, the processor can choose to not lock until two threads actually conflict with each other.^[3]

A simpler version of the test can use the cmpxchg instruction on x86, or the __sync_bool_compare_and_swap built into many Unix compilers.

With the optimizations applied, a sample would look like:

; In C: while(!__sync_bool_compare_and_swap(&locked, 0, 1)) while(locked) __builtin_ia32_pause();

spin_lock:

    mov     ecx, 1             ; Set the ECX register to 1.

retry:

    xor     eax, eax           ; Zero out EAX, because cmpxchg compares against EAX.

    XACQUIRE lock cmpxchg ecx, [locked]

                               ; atomically decide: if locked is zero, write ECX to it.

                               ;  XACQUIRE hints to the processor that we are acquiring a lock.

    je      out                ; If we locked it (old value equal to EAX: 0), return.

pause:

    mov     eax, [locked]      ; Read locked into EAX.

    test    eax, eax           ; Perform the zero-test as before.

    jz      retry              ; If it's zero, we can retry.

    rep nop                    ; Tell the CPU that we are waiting in a spinloop, so it can

                               ;  work on the other thread now. Also written as the "pause".

    jmp     pause              ; Keep check-pausing.

out:

    ret                        ; All done.

spin_unlock:

    XRELEASE mov [locked], 0   ; Assuming the memory ordering rules apply, release the

                               ;  lock variable with a "lock release" hint.

    ret                        ; The lock has been released.

Alternatives[edit]

The primary disadvantage of a spinlock is that, while waiting to acquire a lock, it wastes time that might be productively spent elsewhere. There are two ways to avoid this:

Do not acquire the lock. In many situations it is possible to design data structures that do not require locking, e.g. by using per-thread or per-CPU data and disabling interrupts.
Switch to a different thread while waiting. This typically involves attaching the current thread to a queue of threads waiting for the lock, followed by switching to another thread that is ready to do some useful work. This scheme also has the advantage that it guarantees that resource starvation does not occur as long as all threads eventually relinquish locks they acquire and scheduling decisions can be made about which thread should progress first. Spinlocks that never entail switching, usable by real-time operating systems, are sometimes called raw spinlocks.^[4]

Most operating systems (including Solaris, Mac OS X and FreeBSD) use a hybrid approach called "adaptive mutex". The idea is to use a spinlock when trying to access a resource locked by a currently-running thread, but to sleep if the thread is not currently running. (The latter is always the case on single-processor systems.)^[5]

OpenBSD attempted to replace spinlocks with ticket locks which enforced first-in-first-out behaviour, however this resulted in more CPU usage in the kernel and larger applications, such as Firefox, becoming much slower.^[6]^[7]

References[edit]

^ Silberschatz, Abraham; Galvin, Peter B. (1994). Operating System Concepts (Fourth ed.). Addison-Wesley. pp. 176–179. ISBN 0-201-59292-4.
^ "gcc - x86 spinlock using cmpxchg". Stack Overflow.
^ "New Technologies in the Arm Architecture" (PDF).
^ Jonathan Corbet (9 December 2009). "Spinlock naming resolved". LWN.net. Retrieved 14 May 2013.
^ Silberschatz, Abraham; Galvin, Peter B. (1994). Operating System Concepts (Fourth ed.). Addison-Wesley. p. 198. ISBN 0-201-59292-4.
^ Ted Unangst (2013-06-01). "src/lib/librthread/rthread.c - Revision 1.71".
^ Ted Unangst (2016-05-06). "tedu comment on Locking in WebKit - Lobsters".

External links[edit]

pthread_spin_lock documentation from The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004 Edition
Variety of spinlock Implementations from Concurrency Kit
Article "User-Level Spin Locks - Threads, Processes & IPC" by Gert Boddaert
Article Spin Lock Example in Java
Paper "The Performance of Spin Lock Alternatives for Shared-Memory Multiprocessors" by Thomas E. Anderson
Paper "Algorithms for Scalable Synchronization on Shared-Memory Multiprocessors" by John M. Mellor-Crummey and Michael L. Scott. This paper received the 2006 Dijkstra Prize in Distributed Computing.
Spin-Wait Lock by Jeffrey Richter
Austria C++ SpinLock Class Reference
Interlocked Variable Access(Windows)
Operating Systems: Three Easy Pieces (Chapter: Locks)

https://docs.microsoft.com/en-us/dotnet/standard/threading/spinlock

The SpinLock structure is a low-level, mutual-exclusion synchronization primitive that spins while it waits to acquire a lock. On multicore computers, when wait times are expected to be short and when contention is minimal, SpinLock can perform better than other kinds of locks. However, we recommend that you use SpinLock only when you determine by profiling that the System.Threading.Monitor method or the Interlocked methods are significantly slowing the performance of your program.

SpinLock may yield the time slice of the thread even if it has not yet acquired the lock. It does this to avoid thread-priority inversion, and to enable the garbage collector to make progress. When you use a SpinLock, ensure that no thread can hold the lock for more than a very brief time span, and that no thread can block while it holds the lock.

Because SpinLock is a value type, you must explicitly pass it by reference if you intend the two copies to refer to the same lock.

For more information about how to use this type, see System.Threading.SpinLock. For an example, see How to: Use SpinLock for Low-Level Synchronization.

SpinLock supports a thread-tracking mode that you can use during the development phase to help track the thread that is holding the lock at a specific time. Thread-tracking mode is very useful for debugging, but we recommend that you turn it off in the release version of your program because it may slow performance. For more information, see How to: Enable Thread-Tracking Mode in SpinLock.