Lock-Free-Algorithms-Terms

Lock-Free-Algorithms-Terms

1. Wait-freedom

Wait-freedom means that each thread moves forward regardless of external factors like contention from other threads, other thread blocking. Each operations is executed in a bounded number of steps. It’s the strongest guarantee for synchronization algorithms. Wait-free algorithms usually use such primitives as atomic_exchange, atomic_fetch_add (InterlockedExchange, InterlockedIncrement, InterlockedExchangeAdd, __sync_fetch_and_add), and they do not contain cycles that can be affected by other threads. atomic_compare_exchange primitive (InterlockedCompareExchange, __sync_val_compare_and_swap) is usually not used, because it is usually tied with a “repeat until succeed” cycle.

Wait-freedom 意味着每个线程都可以向前执行，而不会收到其他线程争用，其他线程阻塞之类的外部因素的影响。 每个操作都以有限步骤执行。 这是同步算法的最有力保证。Wait-free 算法通常使用诸如atomic_exchange，atomic_fetch_add（InterlockedExchange，InterlockedIncrement，InterlockedExchangeAdd，__ sync_fetch_and_add）之类的原语，并且它们不包含可能受其他线程影响的循环。 通常不使用atomic_compare_exchange原语（InterlockedCompareExchange，__ sync_val_compare_and_swap），因为这种原语通常与“重复直到成功”循环联系在一起。

下面是wait-free的算法：

void increment_reference_counter(rc_base* obj)
{
    atomic_increment(obj->rc);
}

void decrement_reference_counter(rc_base* obj)
{
    if (0 == atomic_decrement(obj->rc))
        delete obj;
} 

Each thread is able to execute the function in a bounded number of steps regardless of any external factors.

每个线程都能够执行完这个函数在有限的步骤内不管其他的外部因素。

2. Lock-freedom

Lock-freedom means that a system as a whole moves forward regardless of anything. Forward progress for each individual thread is not guaranteed (that is, individual threads can starve). It’s a weaker guarantee than wait-freedom. Lockfree algorithms usually use atomic_compare_exchange primitive (InterlockedCompareExchange, __sync_val_compare_and_swap).

无锁意味着整个系统无论如何都会向前发展。 不能保证每个单独线程的前进进度（也就是说，单个线程可能会饿死）。 这比等待自由要弱。 无锁算法通常使用atomic_compare_exchange原语（InterlockedCompareExchange，__ sync_val_compare_and_swap）.

An example of a lockfree algorithm is:

void stack_push(stack* s, node* n)
{
    node* head;
    do
    {
        head = s->head;
        n->next = head;
    }
    while ( ! atomic_compare_exchange(s->head, head, n));
} 

As can be seen, a thread can “whirl” in the cycle theoretically infinitely. But every repeat of the cycle means that some other thread had made forward progress (that is, successfully pushed a node to the stack). A blocked/interrupted/terminated thread can not prevent forward progress of other threads. Consequently, the system as a whole undoubtedly makes forward progress.

可以看出，线程可以在理论上无限地“旋转”循环。 但是循环的每一次重复都意味着其他一些线程已经取得了进步（也就是说，已经成功地将一个节点推入了堆栈）。 阻塞/中断/终止的线程无法阻止其他线程的前进。 因此，整个系统无疑将取得进步。

3. Obstruction-freedom

Obstruction-freedom guarantee means that a thread makes forward progress only if it does not encounter contention from other threads. That is, two threads can prevent each other’s progress and lead to a livelock. It’s even weaker guarantee than loсk-freedom. This guarantee may look a bit strange at first. However, note that (1) blocked/interrupted/terminated threads can not prevent progress of other threads, and (2) obstruction-free algorithms can be faster than lockfree algorithms.

Obstruction-freedom 保证意味着一个线程仅在不遇到其他线程的争用时才向前推进。 也就是说，两个线程可以阻止彼此的进程并导致活动锁。 它比Lock-freedom更弱。 起初，这种保证可能看起来有些奇怪。 但是，请注意，（1）阻塞/中断/终止的线程无法阻止其他线程的进程，并且（2）无阻塞算法可能比无锁算法更快。

I am unable to come up with a single example, so I refer you to the original paper Obstruction-Free Synchronization: Double-Ended Queues as an Example.

4. Termination-safety

Waitfree, lockfree and obstruction-free algorithms provide a guarantee of termination-safety. That is, a terminated thread does not prevent system-wide forward progress.
无等待，无锁和无障碍算法可确保终止安全。 也就是说，终止的线程不会阻止系统范围内的前进。

5.Blocking Algorithms

It’s the weakest guarantee - basically all bets are off, the system as a whole may not make any forward progress. A blocked/interrupted/terminated thread may prevent system-wide forward progress infinitely. Mutex-based algorithms are also amenable to deadlocks, and a deadlocked system clearly makes no forward progress.

Blocking Algorithms这是最弱的保证-基本上所有赌注都没有了，整个系统可能无法取得任何进步。 阻塞/中断/终止的线程可能会无限阻止整个系统的前进。 基于互斥量的算法也适用于死锁，并且死锁系统显然无法向前推进。

6. Practical Implications

Don’t get it as it’s impossible to create mutex-based programs what make forward progress. It’s indeed possible to create mutex-based programs that do make eventual forward progress, and there are zillions of examples of it out there. Wait-freedom, loсk-freedom are theoretical properties that consider kind of corner cases. However, there are some practical implications as well:

\1. With lockfree algorithms a thread that can make forward progress is always one of the currently running threads, and thus it actually makes forward progress. With mutex-based algorithms there is also usually a thread that can make forward progress, however it may be a currently non-running thread, and thus no actual forward progress happens (at least until, for example, a page will be loaded from disk and/or several context switches happen and/or some amount of active spinning happens).

使用无锁算法，可以向前推进的线程始终是当前正在运行的线程之一，因此实际上可以向前推进。 使用基于互斥量的算法时，通常还会有一个线程可以向前推进，但是它可能是当前未运行的线程，因此不会发生实际的向前进展（至少直到例如从磁盘加载页面之前） 和/或发生多个上下文切换和/或发生一定数量的活动旋转）。

\2. Waitfree, lockfree algorithms can be used in some contexts where lock-based algorithms can not be used. For example, it’s generally unsafe to use locks in signal handlers, because the lock can be currently acquired by the preempted thread, and it instantly leads to a deadlock. Another example is hard real-time systems, where wait-free algorithms are preferable because of strict upper bounds on execution time.

在没有使用基于锁的算法的某些情况下，可以使用无等待，无锁算法。 例如，在信号处理程序中使用锁通常是不安全的，因为该锁当前可以被抢占线程获取，并且立即导致死锁。 另一个例子是硬实时系统，由于严格的执行时间上限，因此最好使用免等待算法。

\3. In some systems (most notably in multi-process systems that use inter-process shared memory for communication) threads can be unexpectedly terminated due to timeouts, fatal failures or by operator’s command. In such systems mutexes are inherently unsafe to use, because, if a terminated thread holds a mutex, the mutex will be never released (yes, there are so called robust mutexes, but that’s another story, and in the end they still require usage of lockfree algorithms or something like that).

在某些系统中（尤其是在使用进程间共享内存进行通信的多进程系统中），线程可能由于超时，致命故障或操作员的命令而意外终止。 在这样的系统中，互斥锁本质上是不安全的，因为如果终止线程持有互斥锁，则该互斥锁将永远不会被释放（是的，有所谓的健壮互斥锁，但这是另一回事了，最后它们仍然需要使用 无锁算法或类似的东西）。

7. Performance/scalability

As you may have noticed, I did not say anything about performance yet. That’s right - the terms are about forward progress guarantees, and are orthogonal to performance. Of course, some lockfree algorithms are faster than mutex-based algorithms, but only by accident. In general lockfree algorithms are slower than analogous algorithms not burdened with forward progress guarantees (think of Quality-Of-Service vs. Best-Effort). Let me refine the point, here I am looking from the point of view of what guarantee your system requires. Lockfree is a subset of blocking (stricter guarantee), so if your system is Ok with blocking (does not require any particular forward progress guarantees), then you can choose the fastest algorithm from blocking/lockfree/wait-free. If your system requires lockfree forward progress guarantees, then you can choose only from lockfree/waitfree. And if your system requires wait-free guarantees, then you can choose only from wait-free algorithms. So blocking is at least as fast as lockfree, while it can be faster (when it happened so that the fastest known algorithm is at least partially blocking).

性能/可扩展性

您可能已经注意到，关于性能我还没有说。没错-术语是关于向前进度的保证，并且与绩效正交。当然，某些无锁算法比基于互斥锁的算法要快，但这只是偶然。通常，无锁算法要比没有前向进度保证（服务质量与尽力而为）的类似算法慢。让我澄清一点，在这里我是从保证系统要求的角度来看的。 Lockfree是阻塞（严格保证）的子集，因此，如果您的系统可以阻塞（不需要任何特定的前向进度保证），则可以从阻塞/无锁定/无等待中选择最快的算法。如果您的系统需要无锁转发进度保证，则只能从无锁/等待中进行选择。而且，如果您的系统需要免等待保证，那么您只能从免等待算法中进行选择。因此，阻塞至少与无锁一样快，而阻塞可以更快（发生这种情况时，最快的已知算法至少会部分阻塞）。

reference:

[1]. http://www.1024cores.net/home/lock-free-algorithms/introduction