Fixed two critical race conditions that prevented multi-threaded module execution: ## Bug #1: ThreadedModuleSystem::registerModule() race condition **Symptom:** Deadlock on first processModules() call **Root Cause:** Worker thread started before being added to workers vector **Fix:** Add worker to vector BEFORE spawning thread (src/ThreadedModuleSystem.cpp:102-108) Before: - Create worker → Start thread → Add to vector (RACE!) - Thread accesses workers[index] before push_back completes After: - Create worker → Add to vector → Start thread (SAFE) - Thread guaranteed to find worker in vector ## Bug #2: stillhammer::createLogger() race condition **Symptom:** Deadlock when multiple threads create loggers simultaneously **Root Cause:** Check-then-register pattern without mutex protection **Fix:** Added static mutex around spdlog::get() + register_logger() (external/StillHammer/logger/src/Logger.cpp:94-96) Before: - Thread 1: check → create → register - Thread 2: check → create → register (RACE on spdlog registry!) After: - Mutex protects entire check-then-register critical section ## Validation & Testing Added comprehensive test suite: - test_threaded_module_system.cpp (6 unit tests) - test_threaded_stress.cpp (5 stress tests: 50 modules × 1000 frames) - test_logger_threadsafe.cpp (concurrent logger creation) - benchmark_threaded_vs_sequential.cpp (performance comparison) - docs/THREADED_MODULE_SYSTEM_VALIDATION.md (full validation report) All tests passing (100%): - ThreadedModuleSystem: ✅ 0.15s - ThreadedStress: ✅ 7.64s - LoggerThreadSafe: ✅ 0.13s ## Impact ThreadedModuleSystem now PRODUCTION READY: - Thread-safe module registration - Stable parallel execution (validated with 50,000+ operations) - Hot-reload working (100 cycles tested) - Logger thread-safe for concurrent module initialization Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| architecture | ||
| implementation | ||
| performance_reports | ||
| plans | ||
| coding_guidelines.md | ||
| DEVELOPER_GUIDE.md | ||
| FEATURES.md | ||
| PLAN_BGFX_RENDERER.md | ||
| PROMPT_UI_MODULE_PHASE6.md | ||
| README.md | ||
| THREADED_MODULE_SYSTEM_VALIDATION.md | ||
| UI_ARCHITECTURE.md | ||
| UI_MODULE_DEMO.md | ||
| UI_MODULE_PHASE2_COMPLETE.md | ||
| UI_MODULE_PHASE3_COMPLETE.md | ||
| UI_MODULE_PHASE6_PROGRESS.md | ||
| UI_MODULE_PHASE7_COMPLETE.md | ||
| UI_RENDERING.md | ||
| UI_TOPICS.md | ||
| UI_WIDGETS.md | ||
| USER_GUIDE.md | ||
GroveEngine Documentation
Overview
GroveEngine is a modular game engine architecture designed for distributed systems and hot-reload development. It provides a clean separation between business logic (modules) and infrastructure (engine, IO, scheduling).
Architecture Documents
Core Systems
-
Data Tree System - Unified config/data/runtime management
- IDataNode/IDataValue/IDataTree interfaces
- JSON backend implementation
- Hot-reload and persistence
- Distributed configuration synchronization
-
Modular Architecture - Module system design
- IModule interface and constraints
- IModuleSystem execution strategies
- Hot-reload workflow
- Claude Code optimization
-
Claude Code Integration - AI development workflow
- Micro-context development
- Hot-reload for rapid iteration
- Module development best practices
Quick Start
Creating a Module
#include <grove/IModule.h>
#include <grove/IDataNode.h>
class TankModule : public IModule {
private:
IIO* m_io;
int m_armor;
double m_speed;
public:
void setConfiguration(const IDataNode& config, IIO* io, ITaskScheduler* scheduler) override {
m_io = io;
m_armor = config.getInt("armor", 100);
m_speed = config.getDouble("speed", 5.0);
}
void process(const IDataNode& input) override {
// Game logic here
// Save state via IIO
auto state = createDataNode({
{"armor", m_armor},
{"speed", m_speed}
});
m_io->publish("save:tank:state", std::move(state));
}
std::unique_ptr<IDataNode> getState() override {
return createDataNode({
{"armor", m_armor},
{"speed", m_speed}
});
}
void setState(const IDataNode& state) override {
m_armor = state.getInt("armor", 100);
m_speed = state.getDouble("speed", 5.0);
}
std::string getType() const override { return "tank"; }
};
Using the Data Tree
#include <grove/DataTreeFactory.h>
// Create tree
auto tree = DataTreeFactory::create("json", "./gamedata");
// Access configuration (read-only)
auto configRoot = tree->getConfigRoot();
auto tankConfig = configRoot->getChild("tanks")->getChild("heavy");
int armor = tankConfig->getInt("armor");
// Access persistent data (read-write)
auto dataRoot = tree->getDataRoot();
auto progress = dataRoot->getChild("campaign")->getChild("progress");
progress->setData(createDataNode({{"level", 5}}));
tree->saveData();
// Hot-reload config
if (tree->reloadIfChanged()) {
// Config changed, refresh modules
}
Key Concepts
Module System
- Modules: 200-300 line business logic units
- IModuleSystem: Execution strategy (Sequential, Threaded, Distributed)
- Hot-reload: Replace modules without restarting
- State preservation: getState/setState for seamless updates
Data Management
- config/: Read-only game configuration (hot-reload, distributed)
- data/: Persistent player data (local saves)
- runtime/: Temporary state (never saved)
Communication
- IIO: Pub/sub messaging between modules
- ITaskScheduler: Delegate heavy computation
- Save pattern: Modules publish "save:*" messages, Engine persists
Distribution
- Coordinator: Master config with hot-reload
- Engines: Local replicas, synchronized config
- Isolation: Each Engine has independent data/
Design Principles
- Interface-based: Work with abstractions (IDataNode, not JsonDataNode)
- Backend-agnostic: Swap implementations without code changes
- Minimal coupling: Modules communicate only via IIO
- Hot-reload first: Development optimized for instant feedback
- Distribution-ready: Config sync, data isolation built-in
Project Status
Implemented ✅
- Complete IDataNode/IDataTree system
- JSON backend (JsonDataValue, JsonDataNode, JsonDataTree)
- Hot-reload for config files
- Save/load for persistent data
- Pattern matching and property queries
- SHA256 hashing for validation
In Progress 🚧
- Coordinator synchronization implementation
- Module system integration with DataTree
- Example modules and tests
Planned 📋
- Binary format backend
- Database backend
- Network synchronization protocol
- Schema validation
- Migration system
Contributing
When adding new features:
- Start with interface definition (.h file)
- Add documentation to this folder
- Implement concrete class
- Update architecture docs
- Write usage examples
Further Reading
Last Updated: 2025-10-28 Engine Version: 1.0.0