From 5f265567d1451941d125a9d5a374263a65ec619b Mon Sep 17 00:00:00 2001 From: Hayodea Hekol Date: Sun, 24 May 2026 13:05:09 -0400 Subject: [PATCH] Explain why CoQutex is superior to LockSet --- include/spinscale/cps/lockSet.h | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/include/spinscale/cps/lockSet.h b/include/spinscale/cps/lockSet.h index 89d2368..e4956e3 100644 --- a/include/spinscale/cps/lockSet.h +++ b/include/spinscale/cps/lockSet.h @@ -15,6 +15,21 @@ class Qutex; /** * @brief LockSet - Manages a collection of locks for acquisition/release + * + * LockSet exists only because the CPS re-enqueuing model had no way to acquire + * locks in a fine-grained way. A LockerAndInvoker could re-post only the entire + * continuation, and only before that continuation began executing; there was no + * mechanism to re-enqueue individual segments within a continuation. The + * practical consequence was that all required Qutexes had to be acquired at + * once up front, before the continuation body could run at all. + * + * releaseQutexEarly() was a partial workaround for finer-grained control, but + * it only helped on the release side and did not solve the fundamental problem + * of acquiring locks one-at-a-time mid-sequence. + * + * co::CoQutex supersedes this abstraction: coroutines can co_await individual + * locks at the points where they are actually needed, which is the finer control + * LockSet and releaseQutexEarly() were aiming for with limited success. */ class LockSet {