# German translations for Python package.
# Copyright (C) 2001 Python Software Foundation
# This file is distributed under the same license as the Python package.
# Automatically generated, 2026.
#
msgid ""
msgstr ""
"Project-Id-Version: Python 3.14\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2026-09-28 03:11+0000\n"
"PO-Revision-Date: 2026-09-23 06:17+0000\n"
"Last-Translator: Automatically generated\n"
"Language-Team: none\n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
#: ../../c-api/synchronization.rst:6
msgid "Synchronization primitives"
msgstr ""
#: ../../c-api/synchronization.rst:8
msgid "The C-API provides a basic mutual exclusion lock."
msgstr ""
#: ../../c-api/synchronization.rst:12
msgid ""
"A mutual exclusion lock. The :c:type:`!PyMutex` should be initialized to "
"zero to represent the unlocked state. For example::"
msgstr ""
#: ../../c-api/synchronization.rst:15
msgid "PyMutex mutex = {0};"
msgstr ""
#: ../../c-api/synchronization.rst:17
msgid ""
"Instances of :c:type:`!PyMutex` should not be copied or moved. Both the "
"contents and address of a :c:type:`!PyMutex` are meaningful, and it must "
"remain at a fixed, writable location in memory."
msgstr ""
#: ../../c-api/synchronization.rst:23
msgid ""
"A :c:type:`!PyMutex` currently occupies one byte, but the size should be "
"considered unstable. The size may change in future Python releases without "
"a deprecation period."
msgstr ""
#: ../../c-api/synchronization.rst:31
msgid ""
"Lock mutex *m*. If another thread has already locked it, the calling thread "
"will block until the mutex is unlocked. While blocked, the thread will "
"temporarily detach the :term:`thread state ` if one "
"exists."
msgstr ""
#: ../../c-api/synchronization.rst:39
msgid ""
"Unlock mutex *m*. The mutex must be locked --- otherwise, the function will "
"issue a fatal error."
msgstr ""
#: ../../c-api/synchronization.rst:46
msgid "Returns non-zero if the mutex *m* is currently locked, zero otherwise."
msgstr ""
#: ../../c-api/synchronization.rst:50
msgid ""
"This function is intended for use in assertions and debugging only and "
"should not be used to make concurrency control decisions, as the lock state "
"may change immediately after the check."
msgstr ""
#: ../../c-api/synchronization.rst:59
msgid "Python critical section API"
msgstr ""
#: ../../c-api/synchronization.rst:61
msgid ""
"The critical section API provides a deadlock avoidance layer on top of per-"
"object locks for :term:`free-threaded ` CPython. They are "
"intended to replace reliance on the :term:`global interpreter lock`, and are "
"no-ops in versions of Python with the global interpreter lock."
msgstr ""
#: ../../c-api/synchronization.rst:66
msgid ""
"Critical sections are intended to be used for custom types implemented in C-"
"API extensions. They should generally not be used with built-in types like :"
"class:`list` and :class:`dict` because their public C-APIs already use "
"critical sections internally, with the notable exception of :c:func:"
"`PyDict_Next`, which requires critical section to be acquired externally."
msgstr ""
#: ../../c-api/synchronization.rst:73
msgid ""
"Critical sections avoid deadlocks by implicitly suspending active critical "
"sections, hence, they do not provide exclusive access such as provided by "
"traditional locks like :c:type:`PyMutex`. When a critical section is "
"started, the per-object lock for the object is acquired. If the code "
"executed inside the critical section calls C-API functions then it can "
"suspend the critical section thereby releasing the per-object lock, so other "
"threads can acquire the per-object lock for the same object."
msgstr ""
#: ../../c-api/synchronization.rst:81
msgid ""
"Variants that accept :c:type:`PyMutex` pointers rather than Python objects "
"are also available. Use these variants to start a critical section in a "
"situation where there is no :c:type:`PyObject` -- for example, when working "
"with a C type that does not extend or wrap :c:type:`PyObject` but still "
"needs to call into the C API in a manner that might lead to deadlocks."
msgstr ""
#: ../../c-api/synchronization.rst:87
msgid ""
"The functions and structs used by the macros are exposed for cases where C "
"macros are not available. They should only be used as in the given macro "
"expansions. Note that the sizes and contents of the structures may change in "
"future Python versions."
msgstr ""
#: ../../c-api/synchronization.rst:94
msgid ""
"Operations that need to lock two objects at once must use :c:macro:"
"`Py_BEGIN_CRITICAL_SECTION2`. You *cannot* use nested critical sections to "
"lock more than one object at once, because the inner critical section may "
"suspend the outer critical sections. This API does not provide a way to "
"lock more than two objects at once."
msgstr ""
#: ../../c-api/synchronization.rst:100
msgid "Example usage::"
msgstr ""
#: ../../c-api/synchronization.rst:102
msgid ""
"static PyObject *\n"
"set_field(MyObject *self, PyObject *value)\n"
"{\n"
" Py_BEGIN_CRITICAL_SECTION(self);\n"
" Py_SETREF(self->field, Py_XNewRef(value));\n"
" Py_END_CRITICAL_SECTION();\n"
" Py_RETURN_NONE;\n"
"}"
msgstr ""
#: ../../c-api/synchronization.rst:111
msgid ""
"In the above example, :c:macro:`Py_SETREF` calls :c:macro:`Py_DECREF`, which "
"can call arbitrary code through an object's deallocation function. The "
"critical section API avoids potential deadlocks due to reentrancy and lock "
"ordering by allowing the runtime to temporarily suspend the critical section "
"if the code triggered by the finalizer blocks and calls :c:func:"
"`PyEval_SaveThread`."
msgstr ""
#: ../../c-api/synchronization.rst:119
msgid ""
"Acquires the per-object lock for the object *op* and begins a critical "
"section."
msgstr ""
#: ../../c-api/synchronization.rst:122 ../../c-api/synchronization.rst:136
#: ../../c-api/synchronization.rst:153 ../../c-api/synchronization.rst:168
#: ../../c-api/synchronization.rst:182 ../../c-api/synchronization.rst:199
msgid "In the free-threaded build, this macro expands to::"
msgstr ""
#: ../../c-api/synchronization.rst:124
msgid ""
"{\n"
" PyCriticalSection _py_cs;\n"
" PyCriticalSection_Begin(&_py_cs, (PyObject*)(op))"
msgstr ""
#: ../../c-api/synchronization.rst:128 ../../c-api/synchronization.rst:174
msgid "In the default build, this macro expands to ``{``."
msgstr ""
#: ../../c-api/synchronization.rst:134
msgid "Locks the mutex *m* and begins a critical section."
msgstr ""
#: ../../c-api/synchronization.rst:138
msgid ""
"{\n"
" PyCriticalSection _py_cs;\n"
" PyCriticalSection_BeginMutex(&_py_cs, m)"
msgstr ""
#: ../../c-api/synchronization.rst:142
msgid ""
"Note that unlike :c:macro:`Py_BEGIN_CRITICAL_SECTION`, there is no cast for "
"the argument of the macro - it must be a :c:type:`PyMutex` pointer."
msgstr ""
#: ../../c-api/synchronization.rst:145 ../../c-api/synchronization.rst:191
msgid "On the default build, this macro expands to ``{``."
msgstr ""
#: ../../c-api/synchronization.rst:151
msgid "Ends the critical section and releases the per-object lock."
msgstr ""
#: ../../c-api/synchronization.rst:155
msgid ""
" PyCriticalSection_End(&_py_cs);\n"
"}"
msgstr ""
#: ../../c-api/synchronization.rst:158 ../../c-api/synchronization.rst:204
msgid "In the default build, this macro expands to ``}``."
msgstr ""
#: ../../c-api/synchronization.rst:164
msgid ""
"Acquires the per-object locks for the objects *a* and *b* and begins a "
"critical section. The locks are acquired in a consistent order (lowest "
"address first) to avoid lock ordering deadlocks."
msgstr ""
#: ../../c-api/synchronization.rst:170
msgid ""
"{\n"
" PyCriticalSection2 _py_cs2;\n"
" PyCriticalSection2_Begin(&_py_cs2, (PyObject*)(a), (PyObject*)(b))"
msgstr ""
#: ../../c-api/synchronization.rst:180
msgid "Locks the mutexes *m1* and *m2* and begins a critical section."
msgstr ""
#: ../../c-api/synchronization.rst:184
msgid ""
"{\n"
" PyCriticalSection2 _py_cs2;\n"
" PyCriticalSection2_BeginMutex(&_py_cs2, m1, m2)"
msgstr ""
#: ../../c-api/synchronization.rst:188
msgid ""
"Note that unlike :c:macro:`Py_BEGIN_CRITICAL_SECTION2`, there is no cast for "
"the arguments of the macro - they must be :c:type:`PyMutex` pointers."
msgstr ""
#: ../../c-api/synchronization.rst:197
msgid "Ends the critical section and releases the per-object locks."
msgstr ""
#: ../../c-api/synchronization.rst:201
msgid ""
" PyCriticalSection2_End(&_py_cs2);\n"
"}"
msgstr ""
#: ../../c-api/synchronization.rst:210
msgid "Legacy locking APIs"
msgstr ""
#: ../../c-api/synchronization.rst:212
msgid ""
"These APIs are obsolete since Python 3.13 with the introduction of :c:type:"
"`PyMutex`."
msgstr ""
#: ../../c-api/synchronization.rst:218
msgid "A pointer to a mutual exclusion lock."
msgstr ""
#: ../../c-api/synchronization.rst:223
msgid "The result of acquiring a lock with a timeout."
msgstr ""
#: ../../c-api/synchronization.rst:229
msgid "Failed to acquire the lock."
msgstr ""
#: ../../c-api/synchronization.rst:233
msgid "The lock was successfully acquired."
msgstr ""
#: ../../c-api/synchronization.rst:237
msgid "The lock was interrupted by a signal."
msgstr ""
#: ../../c-api/synchronization.rst:242
msgid "Allocate a new lock."
msgstr ""
#: ../../c-api/synchronization.rst:244
msgid ""
"On success, this function returns a lock; on failure, this function returns "
"``0`` without an exception set."
msgstr ""
#: ../../c-api/synchronization.rst:247 ../../c-api/synchronization.rst:255
#: ../../c-api/synchronization.rst:275 ../../c-api/synchronization.rst:293
#: ../../c-api/synchronization.rst:301
msgid "The caller does not need to hold an :term:`attached thread state`."
msgstr ""
#: ../../c-api/synchronization.rst:252
msgid ""
"Destroy *lock*. The lock should not be held by any thread when calling this."
msgstr ""
#: ../../c-api/synchronization.rst:260
msgid "Acquire *lock* with a timeout."
msgstr ""
#: ../../c-api/synchronization.rst:262
msgid ""
"This will wait for *microseconds* microseconds to acquire the lock. If the "
"timeout expires, this function returns :c:enumerator:`PY_LOCK_FAILURE`. If "
"*microseconds* is ``-1``, this will wait indefinitely until the lock has "
"been released."
msgstr ""
#: ../../c-api/synchronization.rst:267
msgid ""
"If *intr_flag* is ``1``, acquiring the lock may be interrupted by a signal, "
"in which case this function returns :c:enumerator:`PY_LOCK_INTR`. Upon "
"interruption, it's generally expected that the caller makes a call to :c:"
"func:`Py_MakePendingCalls` to propagate an exception to Python code."
msgstr ""
#: ../../c-api/synchronization.rst:272
msgid ""
"If the lock is successfully acquired, this function returns :c:enumerator:"
"`PY_LOCK_ACQUIRED`."
msgstr ""
#: ../../c-api/synchronization.rst:280
msgid "Acquire *lock*."
msgstr ""
#: ../../c-api/synchronization.rst:282
msgid ""
"If *waitflag* is ``1`` and another thread currently holds the lock, this "
"function will wait until the lock can be acquired and will always return "
"``1``."
msgstr ""
#: ../../c-api/synchronization.rst:286
msgid ""
"If *waitflag* is ``0`` and another thread holds the lock, this function will "
"not wait and instead return ``0``. If the lock is not held by any other "
"thread, then this function will acquire it and return ``1``."
msgstr ""
#: ../../c-api/synchronization.rst:290
msgid ""
"Unlike :c:func:`PyThread_acquire_lock_timed`, acquiring the lock cannot be "
"interrupted by a signal."
msgstr ""
#: ../../c-api/synchronization.rst:298
msgid ""
"Release *lock*. If *lock* is not held, then this function issues a fatal "
"error."
msgstr ""