atomic operation

An operation that appears to execute as a single, indivisible step: no

other thread can observe it half-done, and its effects become visible all

at once. Python does not guarantee that high-level statements are atomic

(for example, ``x += 1`` performs multiple bytecode operations and is not

atomic). Atomicity is only guaranteed where explicitly documented. See

also :term:`race condition` and :term:`data race`.

concurrency

The ability of a computer program to perform multiple tasks at the same

time. Python provides libraries for writing programs that make use of

different forms of concurrency. :mod:`asyncio` is a library for dealing

with asynchronous tasks and coroutines. :mod:`threading` provides

access to operating system threads and :mod:`multiprocessing` to

operating system processes. Multi-core processors can execute threads and

processes on different CPU cores at the same time (see

:term:`parallelism`).

concurrent modification

When multiple threads modify shared data at the same time. Concurrent

modification without proper synchronization can cause

:term:`race conditions <race condition>`, and might also trigger a

:term:`data race <data race>`, data corruption, or both.

data race

A situation where multiple threads access the same memory location

concurrently, at least one of the accesses is a write, and the threads

do not use any synchronization to control their access. Data races

lead to :term:`non-deterministic` behavior and can cause data corruption.

Proper use of :term:`locks <lock>` and other :term:`synchronization primitives

<synchronization primitive>` prevents data races. Note that data races

can only happen in native code, but that :term:`native code` might be

exposed in a Python API. See also :term:`race condition` and

:term:`thread-safe`.

deadlock

A situation in which two or more tasks (threads, processes, or coroutines)

wait indefinitely for each other to release resources or complete actions,

preventing any from making progress. For example, if thread A holds lock

1 and waits for lock 2, while thread B holds lock 2 and waits for lock 1,

both threads will wait indefinitely. In Python this often arises from

acquiring multiple locks in conflicting orders or from circular

join/await dependencies. Deadlocks can be avoided by always acquiring

multiple :term:`locks <lock>` in a consistent order. See also

:term:`lock` and :term:`reentrant`.

global state

Data that is accessible throughout a program, such as module-level

variables, class variables, or C static variables in :term:`extension modules

<extension module>`. In multi-threaded programs, global state shared

between threads typically requires synchronization to avoid

:term:`race conditions <race condition>` and

:term:`data races <data race>`.

in a dictionary. Immutable objects are inherently :term:`thread-safe`

because their state cannot be modified after creation, eliminating concerns

about improperly synchronized :term:`concurrent modification`.

And also please note that :term:`free-threaded <free threading>`

CPython does not guarantee :term:`thread-safe` behavior of iterator

operations.

:term:`race condition` between "the looking" and "the leaping". For example,

the code, ``if key in mapping: return mapping[key]`` can fail if another

This issue can be solved with :term:`locks <lock>` or by using the

:term:`EAFP` approach. See also :term:`thread-safe`.

lock

A :term:`synchronization primitive` that allows only one thread at a

time to access a shared resource. A thread must acquire a lock before

accessing the protected resource and release it afterward. If a thread

attempts to acquire a lock that is already held by another thread, it

will block until the lock becomes available. Python's :mod:`threading`

module provides :class:`~threading.Lock` (a basic lock) and

:class:`~threading.RLock` (a :term:`reentrant` lock). Locks are used

to prevent :term:`race conditions <race condition>` and ensure

:term:`thread-safe` access to shared data. Alternative design patterns

to locks exist such as queues, producer/consumer patterns, and

thread-local state. See also :term:`deadlock`, and :term:`reentrant`.

An :term:`object` with state that is allowed to change during the course

of the program. In multi-threaded programs, mutable objects that are

shared between threads require careful synchronization to avoid

:term:`race conditions <race condition>`. See also :term:`immutable`,

:term:`thread-safe`, and :term:`concurrent modification`.

native code

Code that is compiled to machine instructions and runs directly on the

processor, as opposed to code that is interpreted or runs in a virtual

machine. In the context of Python, native code typically refers to

C, C++, Rust or Fortran code in :term:`extension modules <extension module>`

that can be called from Python. See also :term:`extension module`.

non-deterministic

Behavior where the outcome of a program can vary between executions with

the same inputs. In multi-threaded programs, non-deterministic behavior

often results from :term:`race conditions <race condition>` where the

relative timing or interleaving of threads affects the result.

Proper synchronization using :term:`locks <lock>` and other

:term:`synchronization primitives <synchronization primitive>` helps

ensure deterministic behavior.

parallelism

Executing multiple operations at the same time (e.g. on multiple CPU

cores). In Python builds with the

:term:`global interpreter lock (GIL) <global interpreter lock>`, only one

thread runs Python bytecode at a time, so taking advantage of multiple

CPU cores typically involves multiple processes

(e.g. :mod:`multiprocessing`) or native extensions that release the GIL.

In :term:`free-threaded <free threading>` Python, multiple Python threads

can run Python code simultaneously on different cores.

race condition

A condition of a program where the its behavior

depends on the relative timing or ordering of events, particularly in

multi-threaded programs. Race conditions can lead to

:term:`non-deterministic` behavior and bugs that are difficult to

reproduce. A :term:`data race` is a specific type of race condition

involving unsynchronized access to shared memory. The :term:`LBYL`

coding style is particularly susceptible to race conditions in

multi-threaded code. Using :term:`locks <lock>` and other

:term:`synchronization primitives <synchronization primitive>`

helps prevent race conditions.

reentrant

A property of a function or :term:`lock` that allows it to be called or

acquired multiple times by the same thread without causing errors or a

:term:`deadlock`.

For functions, reentrancy means the function can be safely called again

before a previous invocation has completed, which is important when

functions may be called recursively or from signal handlers. Thread-unsafe

functions may be :term:`non-deterministic` if they're called reentrantly in a

multithreaded program.

For locks, Python's :class:`threading.RLock` (reentrant lock) is

reentrant, meaning a thread that already holds the lock can acquire it

again without blocking. In contrast, :class:`threading.Lock` is not

reentrant - attempting to acquire it twice from the same thread will cause

a deadlock.

See also :term:`lock` and :term:`deadlock`.

synchronization primitive

A basic building block for coordinating (synchronizing) the execution of

multiple threads to ensure :term:`thread-safe` access to shared resources.

Python's :mod:`threading` module provides several synchronization primitives

including :class:`~threading.Lock`, :class:`~threading.RLock`,

:class:`~threading.Semaphore`, :class:`~threading.Condition`,

:class:`~threading.Event`, and :class:`~threading.Barrier`. Additionally,

the :mod:`queue` module provides multi-producer, multi-consumer queues

that are especially useful in multithreaded programs. These

primitives help prevent :term:`race conditions <race condition>` and

coordinate thread execution. See also :term:`lock`.

thread-safe

A module, function, or class that behaves correctly when used by multiple

threads concurrently. Thread-safe code uses appropriate

:term:`synchronization primitives <synchronization primitive>` like

:term:`locks <lock>` to protect shared mutable state, or is designed

to avoid shared mutable state entirely. In the

:term:`free-threaded <free threading>` build, built-in types like

:class:`dict`, :class:`list`, and :class:`set` use internal locking

to make many operations thread-safe, although thread safety is not

necessarily guaranteed. Code that is not thread-safe may experience

:term:`race conditions <race condition>` and :term:`data races <data race>`

when used in multi-threaded programs.