<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">
<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">

<style type="text/css">


</style>

<title>Definition of Lock-Free</title>
</head>
<body>
<h1>Definition of Lock-Free</h1>

<p>
ISO/IEC JTC1 SC22 WG21 N3927 - 2014-02-13
</p>

<p>
Lawrence Crowl, Lawrence@Crowl.org
</p>

<h2>Introduction</h2>

<p>
This paper addresses issue LWG 2075:
Progress guarantees, lock-free property, and scheduling assumptions.
This issue is also US 5 in
N3733 ISO/IEC CD 14882, C++ 2014, National Body Comments.
</p>

<h2>Wording</h2>

<h3>1.10 Multi-threaded executions and data races [intro.multithread]</h3>

<p>
Paragraph 2 remains unchanged as follows.
</p>

<blockquote>

<p>
Implementations should ensure that all unblocked threads
eventually make progress.
[<i>Note:</i>
Standard library functions may silently block on I/O or locks.
Factors in the execution environment,
including externally-imposed thread priorities,
may prevent an implementation
from making certain guarantees of forward progress.
&mdash;<i>end note</i>]
</p>

</blockquote>

<p>
Add a new paragraph after paragraph 2 as follows.
</p>

<blockquote>

<p>
<ins>
Executions of atomic functions
that are either defined to be lock-free (29.7 [atomics.flag])
or indicated as lock-free (29.4 [atomics.lockfree])
are <dfn>lock-free executions</dfn>.
</ins>
</p>

<ul>

<li><p>
<ins>
If there is only one unblocked thread,
a lock-free execution in that thread shall complete.
[<i>Note:</i>
Concurrently executing threads may prevent progress of a lock-free execution.
For example, this situation can occur with
load-locked store-conditional implementations.
This property is sometimes called obstruction-free.
&mdash;<i>end note</i>]
</ins>
</p></li>

<li><p>
<ins>
When one or more lock-free executions run concurrently,
at least one should complete.
[<i>Note:</i>
It is difficult for some implementations
to provide absolute guarantees to this effect,
since repeated and particularly inopportune interference from other threads
may prevent forward progress,
e.g. by repeatedly stealing a cache line for unrelated purposes
between load-locked and store-conditional instructions.
Implementations should ensure that
such effects cannot indefinitely delay progress
under expected operating conditions,
and that such anomalies can therefore safely be ignored by programmers.
This property is sometimes called lock-free
outside this International Standard.
&mdash;<i>end note</i>]
</ins>
</p></li>

</ul>

</blockquote>

</body></html>
