Implement a multi-threaded transaction scheduler

[bmuddha]

This introduces a new multi-threaded transaction scheduler to the magicblock-processor, replacing the previous single-threaded implementation. This new design significantly improves performance by processing non-conflicting transactions in parallel.

The core of this feature is a central scheduler that dispatches transactions to a pool of worker threads. A lock-free coordination mechanism based on bitmasks is used to manage account access, ensuring that only transactions with non-overlapping write sets are executed concurrently.

Changes in this PR include:

• Multi-threaded Scheduler: Implementation of the main scheduler loop, worker pool, and event handling.
• Execution Coordinator: A central component that manages transaction dependencies, queues blocked transactions, and tracks ready executors.
• Account Locking: A highly efficient, bitmask-based locking mechanism for read/write access to accounts.

Greptile Overview

Updated On: 2025-10-01 12:37:32 UTC

Summary

This PR introduces a significant architectural change to the MagicBlock validator by implementing a multi-threaded transaction scheduler that replaces the previous single-threaded implementation. The new scheduler enables parallel processing of non-conflicting transactions, which should substantially improve throughput performance.

The core architecture consists of three main components:

1. Multi-threaded Scheduler: A central dispatcher that manages a pool of worker threads and coordinates transaction distribution. The scheduler uses channels for communication and implements a biased event loop that prioritizes ready executors.

2. ExecutionCoordinator: A state management component that tracks executor readiness, manages transaction queuing for blocked operations, and handles dependency resolution. It maintains maps of ready executors and blocked transactions, automatically rescheduling transactions when their dependencies are resolved.

3. Bitmask-based Account Locking: A high-performance locking mechanism that uses a single u64 per account to represent lock state. The MSB indicates write locks while remaining bits track read locks for up to 63 concurrent executors. This approach provides O(1) lock operations and efficient contention detection.

The implementation includes dynamic CPU-aware thread allocation, dedicating half of available cores to async I/O operations (RPC, WebSocket services) and the other half to transaction execution. The scheduler integrates with the existing TransactionExecutor infrastructure, maintaining compatibility with the current transaction processing pipeline while adding concurrency capabilities.

The changes span multiple crates, adding dependencies for high-performance hashing (rustc-hash) and CPU detection (num_cpus), and include comprehensive test coverage for the coordination logic.

Important Files Changed

Changed Files

Filename	Score	Overview
magicblock-processor/src/scheduler/locks.rs	1/5	CRITICAL ISSUES: New bitmask-based account locking with thread safety violations, debug code, and potential double-unlock bugs
magicblock-processor/src/scheduler/mod.rs	3/5	Main multi-threaded scheduler implementation with some error handling concerns and unsafe code
magicblock-processor/src/scheduler/coordinator.rs	3/5	ExecutionCoordinator for transaction dependency management with potential logic issues in ID resolution
magicblock-processor/src/scheduler/tests.rs	4/5	Comprehensive test suite with debug statements that should be removed
magicblock-processor/src/scheduler.rs	4/5	Complete refactor from single to multi-threaded scheduler architecture
magicblock-processor/src/executor/mod.rs	4/5	Updated executor to use new ExecutorId type for multi-threaded coordination
magicblock-api/src/magic_validator.rs	5/5	Clean implementation of dynamic thread allocation for transaction executors
magicblock-validator/src/main.rs	5/5	Well-structured runtime configuration splitting CPU resources between async and execution threads
magicblock-processor/src/lib.rs	5/5	Simple cleanup removing unused WorkerId type and adding scheduler module export
Cargo.toml	5/5	Addition of rustc-hash dependency for performance optimization
magicblock-processor/Cargo.toml	5/5	Dependencies added to support multi-threaded scheduler functionality
magicblock-validator/Cargo.toml	5/5	Addition of num_cpus dependency for dynamic CPU detection
magicblock-api/Cargo.toml	5/5	Addition of num_cpus dependency for CPU-aware thread allocation

Confidence score: 2/5

• This PR contains serious implementation issues that could cause race conditions, crashes, and data corruption in production
• Score reflects critical thread safety violations in the core locking mechanism and several unsafe code patterns that need immediate attention
• Pay close attention to magicblock-processor/src/scheduler/locks.rs which has multiple critical bugs that must be fixed before merge

Sequence Diagram

sequenceDiagram
    participant User
    participant TransactionScheduler
    participant ExecutionCoordinator
    participant ExecutorPool as "TransactionExecutor Pool"
    participant AccountsDB
    participant Ledger
    participant RPC as "RPC/WebSocket Server"

    User->>RPC: "Submit Transaction"
    RPC->>TransactionScheduler: "ProcessableTransaction via channel"
    
    TransactionScheduler->>ExecutionCoordinator: "get_ready_executor()"
    ExecutionCoordinator-->>TransactionScheduler: "ExecutorId"
    
    TransactionScheduler->>ExecutionCoordinator: "try_acquire_locks(executor, transaction)"
    ExecutionCoordinator->>ExecutionCoordinator: "Check

Loading

[greptile-apps]

_{13 files reviewed, 9 comments}

_{Edit Code Review Agent Settings | Greptile}