[PR #376] fix: Remove race condition in memory allocator initialization #398

Open
opened 2026-10-26 09:49:54 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/deepseek-ai/3FS/pull/376
Author: @yurekami
Created: 1/4/2026
Status: 🔄 Open

Base: main ← Head: fix/memory-allocator-race-condition


📝 Commits (1)

  • 5e76874 fix: Remove race condition in memory allocator initialization

📊 Changes

1 file changed (+2 additions, -9 deletions)

View changed files

📝 src/memory/common/GlobalMemoryAllocator.cc (+2 -9)

📄 Description

Summary

  • Fixes #315: Potential Race Condition in Memory Allocator Initialization
  • Removes the unsynchronized gAllocatorInited flag that caused a race condition
  • Relies solely on std::call_once which provides proper thread-safety guarantees

Problem

The original code had a race condition in GlobalMemoryAllocator.cc:

static bool gAllocatorInited = false;  // Plain bool, not atomic

void *allocate(size_t size) {
  if (!gAllocatorInited) {  // Multiple threads can pass this check
    std::call_once(gInitOnce, loadMemoryAllocatorLib);
    gAllocatorInited = true;  // Can be reordered with gAllocator write
  }

Issues:

  1. gAllocatorInited is a plain bool, not atomic - no synchronization
  2. Instruction reordering: gAllocatorInited = true can execute before std::call_once fully completes
  3. Memory visibility: other threads may see gAllocatorInited = true while gAllocator is still uninitialized

Solution

Remove the redundant flag and rely solely on std::call_once:

void *allocate(size_t size) {
  std::call_once(gInitOnce, loadMemoryAllocatorLib);

Why this works:

  • std::call_once provides full happens-before guarantees (C++11 standard)
  • After first execution, call_once becomes a fast single atomic load (efficient fast-path)
  • No performance degradation - simpler code with same or better performance

Test plan

  • Verify existing unit tests pass
  • Code review for thread-safety correctness
  • The fix is minimal and follows the principle of relying on well-tested standard library primitives

🤖 Generated with Claude Code


🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/deepseek-ai/3FS/pull/376 **Author:** [@yurekami](https://github.com/yurekami) **Created:** 1/4/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/memory-allocator-race-condition` --- ### 📝 Commits (1) - [`5e76874`](https://github.com/deepseek-ai/3FS/commit/5e76874ca1db047857cf2ae5a4c3ecda52b7562d) fix: Remove race condition in memory allocator initialization ### 📊 Changes **1 file changed** (+2 additions, -9 deletions) <details> <summary>View changed files</summary> 📝 `src/memory/common/GlobalMemoryAllocator.cc` (+2 -9) </details> ### 📄 Description ## Summary - Fixes #315: Potential Race Condition in Memory Allocator Initialization - Removes the unsynchronized `gAllocatorInited` flag that caused a race condition - Relies solely on `std::call_once` which provides proper thread-safety guarantees ## Problem The original code had a race condition in `GlobalMemoryAllocator.cc`: ```cpp static bool gAllocatorInited = false; // Plain bool, not atomic void *allocate(size_t size) { if (!gAllocatorInited) { // Multiple threads can pass this check std::call_once(gInitOnce, loadMemoryAllocatorLib); gAllocatorInited = true; // Can be reordered with gAllocator write } ``` **Issues:** 1. `gAllocatorInited` is a plain `bool`, not atomic - no synchronization 2. Instruction reordering: `gAllocatorInited = true` can execute before `std::call_once` fully completes 3. Memory visibility: other threads may see `gAllocatorInited = true` while `gAllocator` is still uninitialized ## Solution Remove the redundant flag and rely solely on `std::call_once`: ```cpp void *allocate(size_t size) { std::call_once(gInitOnce, loadMemoryAllocatorLib); ``` **Why this works:** - `std::call_once` provides full happens-before guarantees (C++11 standard) - After first execution, `call_once` becomes a fast single atomic load (efficient fast-path) - No performance degradation - simpler code with same or better performance ## Test plan - [ ] Verify existing unit tests pass - [ ] Code review for thread-safety correctness - [ ] The fix is minimal and follows the principle of relying on well-tested standard library primitives 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Sign in to join this conversation.
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/3FS#398
No description provided.