Buckets:
| // Python critical sections | |
| // | |
| // Conceptually, critical sections are a deadlock avoidance layer on top of | |
| // per-object locks. These helpers, in combination with those locks, replace | |
| // our usage of the global interpreter lock to provide thread-safety for | |
| // otherwise thread-unsafe objects, such as dict. | |
| // | |
| // NOTE: These APIs are no-ops in non-free-threaded builds. | |
| // | |
| // Straightforward per-object locking could introduce deadlocks that were not | |
| // present when running with the GIL. Threads may hold locks for multiple | |
| // objects simultaneously because Python operations can nest. If threads were | |
| // to acquire the same locks in different orders, they would deadlock. | |
| // | |
| // One way to avoid deadlocks is to allow threads to hold only the lock (or | |
| // locks) for a single operation at a time (typically a single lock, but some | |
| // operations involve two locks). When a thread begins a nested operation it | |
| // could suspend the locks for any outer operation: before beginning the nested | |
| // operation, the locks for the outer operation are released and when the | |
| // nested operation completes, the locks for the outer operation are | |
| // reacquired. | |
| // | |
| // To improve performance, this API uses a variation of the above scheme. | |
| // Instead of immediately suspending locks any time a nested operation begins, | |
| // locks are only suspended if the thread would block. This reduces the number | |
| // of lock acquisitions and releases for nested operations, while still | |
| // avoiding deadlocks. | |
| // | |
| // Additionally, the locks for any active operation are suspended around | |
| // other potentially blocking operations, such as I/O. This is because the | |
| // interaction between locks and blocking operations can lead to deadlocks in | |
| // the same way as the interaction between multiple locks. | |
| // | |
| // Each thread's critical sections and their corresponding locks are tracked in | |
| // a stack in `PyThreadState.critical_section`. When a thread calls | |
| // `_PyThreadState_Detach()`, such as before a blocking I/O operation or when | |
| // waiting to acquire a lock, the thread suspends all of its active critical | |
| // sections, temporarily releasing the associated locks. When the thread calls | |
| // `_PyThreadState_Attach()`, it resumes the top-most (i.e., most recent) | |
| // critical section by reacquiring the associated lock or locks. See | |
| // `_PyCriticalSection_Resume()`. | |
| // | |
| // NOTE: Only the top-most critical section is guaranteed to be active. | |
| // Operations that need to lock two objects at once must use | |
| // `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 (though it could be added later | |
| // if actually needed). | |
| // | |
| // NOTE: Critical sections implicitly behave like reentrant locks because | |
| // attempting to acquire the same lock will suspend any outer (earlier) | |
| // critical sections. However, they are less efficient for this use case than | |
| // purposefully designed reentrant locks. | |
| // | |
| // Example usage: | |
| // Py_BEGIN_CRITICAL_SECTION(op); | |
| // ... | |
| // Py_END_CRITICAL_SECTION(); | |
| // | |
| // To lock two objects at once: | |
| // Py_BEGIN_CRITICAL_SECTION2(op1, op2); | |
| // ... | |
| // Py_END_CRITICAL_SECTION2(); | |
| typedef struct PyCriticalSection PyCriticalSection; | |
| typedef struct PyCriticalSection2 PyCriticalSection2; | |
| PyAPI_FUNC(void) | |
| PyCriticalSection_Begin(PyCriticalSection *c, PyObject *op); | |
| PyAPI_FUNC(void) | |
| PyCriticalSection_End(PyCriticalSection *c); | |
| PyAPI_FUNC(void) | |
| PyCriticalSection2_Begin(PyCriticalSection2 *c, PyObject *a, PyObject *b); | |
| PyAPI_FUNC(void) | |
| PyCriticalSection2_End(PyCriticalSection2 *c); | |
| // NOTE: the contents of this struct are private and may change betweeen | |
| // Python releases without a deprecation period. | |
| struct PyCriticalSection { | |
| // Tagged pointer to an outer active critical section (or 0). | |
| uintptr_t _cs_prev; | |
| // Mutex used to protect critical section | |
| PyMutex *_cs_mutex; | |
| }; | |
| // A critical section protected by two mutexes. Use | |
| // Py_BEGIN_CRITICAL_SECTION2 and Py_END_CRITICAL_SECTION2. | |
| // NOTE: the contents of this struct are private and may change betweeen | |
| // Python releases without a deprecation period. | |
| struct PyCriticalSection2 { | |
| PyCriticalSection _cs_base; | |
| PyMutex *_cs_mutex2; | |
| }; | |
Xet Storage Details
- Size:
- 5.59 kB
- Xet hash:
- 46c7d198777acd2db4a26021cce198d7871671f4668ec56f5ff908c5b5e84a68
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.