-
-
Notifications
You must be signed in to change notification settings - Fork 33.7k
gh-142518: Document thread-safety guarantees of list operations #142519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
fd400f0
38483c9
cc5c2f0
2292896
2b9e711
688b25a
11e8072
8728c54
f09430b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1436,6 +1436,109 @@ application). | |
| list appear empty for the duration, and raises :exc:`ValueError` if it can | ||
| detect that the list has been mutated during a sort. | ||
|
|
||
| .. admonition:: Thread safety | ||
|
|
||
| Reading a single element from a :class:`list` is | ||
| :term:`atomic <atomic operation>`: | ||
|
|
||
| .. code-block:: | ||
| :class: green | ||
|
|
||
| lst[i] # list.__getitem__ | ||
|
|
||
| The following methods traverse the list and use :term:`atomic <atomic operation>` | ||
| reads of each item to perform their function. That means that they may | ||
| return results affected by concurrent modifications: | ||
|
|
||
| .. code-block:: | ||
| :class: maybe | ||
|
|
||
| item in lst | ||
| lst.index(item) | ||
| lst.count(item) | ||
|
|
||
| All of the above methods/operations are also lock-free. They do not block | ||
| concurrent modifications. Other operations that hold a lock will not block | ||
| these from observing intermediate states. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is "intermediate states" correct, or is it just that readers might observe the state either before or after concurrent modification? The way it's written now a very literal-minded reader might conclude that a reader might observe a torn read or other C data race.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not about data races, it's about intermediate states when the lock-free operations race with operations that touch multiple elements. For example, if |
||
|
|
||
| All other operations from here on block using the per-object lock. | ||
|
|
||
| Writing a single item via ``lst[i] = x`` is safe to call from multiple | ||
| threads and will not corrupt the list. | ||
|
|
||
| The following operations return new objects and appear | ||
| :term:`atomic <atomic operation>` to other threads: | ||
|
|
||
| .. code-block:: | ||
| :class: good | ||
|
|
||
| lst1 + lst2 # concatenates two lists into a new list | ||
| x * lst # repeats lst x times into a new list | ||
| lst.copy() # returns a shallow copy of the list | ||
|
|
||
| Methods that only operate on a single elements with no shifting required are | ||
| :term:`atomic <atomic operation>`: | ||
|
|
||
| .. code-block:: | ||
| :class: good | ||
|
|
||
| lst.append(x) # append to the end of the list, no shifting required | ||
| lst.pop() # pop element from the end of the list, no shifting required | ||
|
|
||
| The :meth:`~list.clear` method is also :term:`atomic <atomic operation>`. | ||
| Other threads cannot observe elements being removed. | ||
|
|
||
| The :meth:`~list.sort` method is not :term:`atomic <atomic operation>`. | ||
| Other threads cannot observe intermediate states during sorting, but the | ||
| list appears empty for the duration of the sort. | ||
|
|
||
| The following operations may allow lock-free operations to observe | ||
| intermediate states since they modify multiple elements in place: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not clear to me what "intermediate states" means here. See my comment above. Would help maybe to clarify globally (i.e. somewhere not in the list docs) what observing an object in an intermediate state means. Is any possible layout of the list while it's being processed possible? |
||
|
|
||
| .. code-block:: | ||
| :class: maybe | ||
|
|
||
| lst.insert(idx, item) # shifts elements | ||
| lst.pop(idx) # idx not at the end of the list, shifts elements | ||
| lst *= x # copies elements in place | ||
|
|
||
| The :meth:`~list.remove` method may allow concurrent modifications since | ||
| element comparison may execute arbitrary Python code (via | ||
| :meth:`~object.__eq__`). | ||
|
|
||
| :meth:`~list.extend` is safe to call from multiple threads. However, its | ||
| guarantees depend on the iterable passed to it. If it is a :class:`list`, a | ||
| :class:`tuple`, a :class:`set`, a :class:`frozenset`, a :class:`dict` or a | ||
| :ref:`dictionary view object <dict-views>` (but not their subclasses), the | ||
| ``extend`` operation is safe from concurrent modifications to the iterable. | ||
| Otherwise, an iterator is created which can be concurrently modified by | ||
| another thread. The same applies to inplace concatenation of a list with | ||
| other iterables when using ``lst += iterable``. | ||
|
|
||
| Similarly, assigning to a list slice with ``lst[i:j] = iterable`` is safe | ||
| to call from multiple threads, but ``iterable`` is only locked when it is | ||
| also a :class:`list` (but not its subclasses). | ||
|
|
||
| Operations that involve multiple accesses, as well as iteration, are never | ||
| atomic. For example: | ||
|
|
||
| .. code-block:: | ||
| :class: bad | ||
|
|
||
| # NOT atomic: read-modify-write | ||
| lst[i] = lst[i] + 1 | ||
|
|
||
| # NOT atomic: check-then-act | ||
| if lst: | ||
| item = lst.pop() | ||
|
|
||
| # NOT thread-safe: iteration while modifying | ||
| for item in lst: | ||
| process(item) # another thread may modify lst | ||
|
|
||
| Consider external synchronization when sharing :class:`list` instances | ||
| across threads. See :ref:`freethreading-python-howto` for more information. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is getting long enough that maybe it deserves to be in its own page in the reference docs, along with thread-safety notes for all the builtin types. Then we can link to those reference docs from here. I think our hope when we originally wanted to include these notes directly in the docs for the builtins was that these notes would be pretty short. But it turns out there are a decent number of caveats and that hope might not be realistic.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with this. Splitting everything out in a new page in the reference docs and then cross-linking sounds like the better approach, especially since |
||
|
|
||
|
|
||
| .. _typesseq-tuple: | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe this could say something like “Operations/methods that involve iteration are generally not atomic, except when used with specific built-in types”, and iteration itself can be moved here?
Mentioning iteration might help people make sense of this, i.e. it's no longer two arbitrary lists of operations/methods.
Then the
badsection below would be left only with examples of “manually” combining multiple operations.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know how I feel about this. "Operations/methods that involve iteration are generally not atomic" is probably not a mnemonic we want people to use, because there are methods that are atomic but traverse the list. Granted most of those are ones that also mutate it, but e.g.
list.copydoesn't.But the idea of separating iteration from manually combining multiple operations is good. Maybe we should do just that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good.
(I guess it's “operations that involve arbitrary iterators and/or comparison functions”, but that's too long; readers whom that would help can figure it out from the list.)
As for iteration, it sounds like the guarantees are the same for single-threaded code: iteration of a list that is being modified may skip elements or yield repeated elements, but will not crash or produce elements that were never part of the list. Is that right?
Is this the place to document list iterators -- i.e. what happens if you use a shared iterator in several threads?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've completely reworded the docs to account for lock-free operations. Is this better?
I think documenting iterators should be done in the
Iteratordocs, not really individually for each iterator type.