Skip to content

Commit 309771a

Browse files
bushidocodesclaude
andauthored
chore: remove unused mutex from the deque request scheduler (#397)
The deque-backed global request scheduler (FIFO) is a Chase-Lev work-stealing deque used as single-producer / multi-consumer: only the listener thread pushes (the owner end) and worker threads only steal (the lock-free opposite end, coordinated by a CAS). deque_pop -- the other owner operation -- is never used, so the multi-owner case the deque comments warn about does not arise, and no lock is required. global_request_scheduler_deque_mutex (carrying a "Should this be used???" TODO) was never locked anywhere -- dead code. Remove it and document why the structure is safe without a lock. No functional change. Verified: builds; FIFO serves 20,000/20,000 requests as 200s with no errors. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1 parent 4e53994 commit 309771a

1 file changed

Lines changed: 8 additions & 5 deletions

File tree

runtime/src/global_request_scheduler_deque.c

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6,12 +6,15 @@
66

77
static struct deque_sandbox *global_request_scheduler_deque;
88

9-
/* TODO: Should this be used??? */
10-
static pthread_mutex_t global_request_scheduler_deque_mutex = PTHREAD_MUTEX_INITIALIZER;
11-
129
/**
13-
* Pushes a sandbox to the global deque
14-
* @param sandbox_raw
10+
* Pushes a sandbox to the global deque.
11+
*
12+
* No lock is required: this is a work-stealing deque used as a single-producer / multi-consumer queue. Only the
13+
* listener thread ever pushes (the "owner" end), while worker threads only ever steal (the lock-free opposite
14+
* end, coordinated by a CAS). The owner's other operation, deque_pop, is never used, so the multi-owner case the
15+
* deque comments warn about does not arise here.
16+
*
17+
* @param sandbox
1518
* @returns pointer to sandbox if added. NULL otherwise
1619
*/
1720
static struct sandbox *

0 commit comments

Comments
 (0)