The MycoEco Kernel: Lock-Free Determinism at Scale

For decades, a commonly held assumption in the operating systems community has been that deterministic execution requires serialisation, and serialisation limits multi-core performance. If you want reproducible execution, you must use locks, mutexes, and barriers that force cores to wait for each other. The more cores you add, the more contention you face.

This assumption has shaped the design of many operating systems. Most general-purpose systems use schedulers optimised for throughput, with reproducibility as a secondary concern. Safety-critical systems have often accepted performance trade-offs from heavy locking or limited their use of multi-core capabilities.

The MycoEco kernel demonstrates an alternative architectural approach.

Through event-based architecture and deterministic scheduling, MycoEco achieves lock-free deterministic execution across multiple cores. No mutexes. No spinlocks. No barriers. Just deterministic coordination that scales.

This isn’t theoretical. The implementation exists, passes 46 automated tests including multi-core determinism verification, and runs in under 256KB of kernel space.

The Lock Trade-offs

To understand MycoEco’s approach, it helps to understand why conventional systems use locks.

Race Conditions in Shared Memory

Multi-core processors share memory. When two cores try to modify the same memory location simultaneously, the result depends on timing—which core’s write happens last. This is a race condition, and it makes execution non-deterministic.

The traditional solution: locks. Core A acquires a mutex, modifies the shared data, releases the mutex. Core B waits. This ensures only one core accesses shared data at a time, addressing the race condition.

But locks introduce well-known trade-offs:

Performance considerations: Cores spend time waiting rather than computing. With N cores, adding more cores can yield diminishing returns as contention increases.

Priority inversion: A low-priority thread holding a lock can block high-priority threads, complicating real-time guarantees.

Deadlock risk: Locks taken in different orders can deadlock, requiring careful prevention schemes.

Composability challenges: Lock-based code doesn’t always compose cleanly—combining two lock-free modules can create potential deadlocks.

For safety-critical systems: locks do not inherently guarantee reproducible execution order. Lock acquisition order can still depend on timing. Thread A might acquire the lock first in one execution, Thread B in another. The execution is serialised but not necessarily deterministic.

The Conventional Trade-off

Many systems have been designed under assumptions that prioritise either determinism or scalability:

• Option 1: Use locks, accept performance trade-offs and potential timing variability
• Option 2: Go lock-free, accept non-determinism from race conditions

Safety-critical systems have often chosen Option 1. High-performance systems have often chosen Option 2. Achieving both determinism and performance has been considered challenging.

MycoEco explores a different point in this design space.

Event-Based Architecture: The Key Insight

MycoEco’s approach is based on recognising that determinism doesn’t require serialisation—it requires deterministic ordering.

Instead of preventing cores from executing simultaneously, MycoEco is designed to ensure that when they do execute simultaneously, the result is deterministic. The key is replacing shared memory communication with event-based communication.

Events as First-Class Primitives

In MycoEco, cores don’t share memory. They communicate through events.

An event is a self-contained message containing:

• Tick number: When it should be processed
• Source core: Which core generated it
• Payload: Data being communicated
• Deterministic hash: Cryptographic fingerprint for integrity verification

Events are immutable once created. They flow through the system in deterministic order, processed at tick boundaries.

This is the fundamental insight. Determinism doesn’t require cores to execute in lockstep. It requires that events be processed in deterministic order, and that each event’s effect be deterministic.

The Deterministic Scheduling Engine (DSE)

MycoEco’s DSE implements deterministic event ordering without locks. At each tick:

1. Event collection: All cores submit events for the current tick
2. Deterministic sorting: Events are ordered by a deterministic function (tick number, source core, event hash)
3. Slot assignment: Each event is assigned to a processing slot
4. Parallel execution: Cores execute their assigned events in parallel

The critical property: slot assignment is deterministic. Given the same set of events, the DSE always assigns them to the same slots. This means:

• Core A always processes the same events in the same order
• Core B always processes the same events in the same order
• The relative timing of A and B doesn’t matter—only the deterministic assignment

No locks. No waiting. Just deterministic coordination.

Replay: Verification of Determinism

A key test of a deterministic system is replay: can you reproduce execution consistently?

MycoEco’s test suite includes multi-core replay verification:

[Replay Tests (Determinism Verification)]
  replay_checkpoint... PASS
  replay_determinism... PASS
  replay_from_checkpoint... PASS
  replay_multicore_determinism... PASS

These tests verify:

Single-core replay: Execute a sequence of operations, checkpoint state, replay from checkpoint → identical final state

Multi-core replay: Execute on 4 cores, checkpoint, replay on different hardware → byte-identical final state

Checkpoint-restart: Stop execution mid-tick, save complete state, restart on different cores → execution continues identically

The replay_multicore_determinism test provides strong internal verification. It runs identical workloads on multiple cores, checksums the final state, then replays the execution and verifies the checksum matches. This test has passed consistently in internal testing across different hardware configurations.

Traditional multi-threaded systems typically cannot pass this test reliably. Running the same program twice may produce different thread interleavings, different memory access patterns, different final states. With MycoEco, the final state is designed to be determined by the initial state and event sequence.

Biological Inspiration: Mycelial Networks

The name “MycoEco” draws from mycology—the study of fungal networks. Mycelium exhibits emergent coordination without central control:

• Decentralised decision-making: No single “master” node coordinates the network
• Event propagation: Chemical signals propagate through the network deterministically
• Resource allocation: Nutrients flow to where they’re needed without explicit orchestration
• Fault tolerance: The network adapts when parts are damaged

MycoEco mirrors these properties:

No master core: Each core is equal. There’s no master that serialises operations.

Event propagation: Events flow through the kernel like chemical signals through mycelium—deterministically, without central coordination.

Load balancing: The DSE distributes events across cores based on deterministic assignment, naturally balancing load.

Resilience: If a core fails, events can be reassigned to surviving cores. The system adapts without violating determinism.

This biological metaphor reflects a fundamental architectural principle: emergent order from deterministic rules, not imposed order from central control.

Performance Characteristics

Lock-free determinism sounds promising in theory, but how does it scale in practice?

Note: Performance figures are indicative and depend on workload characteristics, event rates, and hardware configuration.

Overhead Analysis

MycoEco adds three sources of overhead compared to non-deterministic execution:

1. Event construction (~50 CPU cycles per event, indicative)
2. Deterministic sorting (O(N log N) where N = events per tick)
3. Digest computation (cryptographic hashing for verification)

Combined, these add approximately 2-5% overhead compared to an equivalent non-deterministic system in internal testing. This is substantially less than lock-based approaches, which can incur 20-40% overhead from contention and context switching in high-contention scenarios.

Scaling Properties

Traditional locked systems can show diminishing returns beyond a certain core count. Adding more cores increases contention, potentially causing throughput to plateau or decrease.

MycoEco is designed to show positive scaling up to the point where event sorting becomes the bottleneck. With typical workloads (< 1000 events per tick), this can allow efficient scaling to 8-16 cores.

The key difference: MycoEco’s performance is designed to be predictable. Worst-case execution time can be bounded. With locks, worst-case can be difficult to bound if contention patterns vary.

Real-Time Considerations

Safety-critical systems require hard real-time guarantees: operations must complete within bounded time. Locks can complicate this through priority inversion and variable blocking times.

MycoEco is designed to provide deterministic timing:

Bounded event processing: Each event processes in time determined by the event handler

Bounded sorting: Event sorting takes O(N log N) where N is bounded by the maximum events per tick

No priority inversion: Events execute in deterministic order. No low-priority event can block high-priority execution through lock contention.

Worst-case execution time (WCET): Can be analysed statically from the event handlers and maximum event counts

This design supports certification to standards like DO-178C Level A and ISO 26262 ASIL D, which require demonstrable worst-case timing bounds.

PBAS-6 Guardrails: Safety Envelopes

MycoEco integrates PBAS-6 (Progressive Bounded Autonomous Systems) guardrails that enforce safety envelopes during execution. These are runtime checks designed to ensure the system remains within safety constraints.

At each tick, PBAS-6 checks:

• State validity: Is the system state within safe bounds?
• Event safety: Do pending events violate safety constraints?
• Escalation triggers: Has the system approached constraint boundaries?

If a violation is detected, PBAS-6 escalates to a safer operating mode:

NOMINAL  → Normal operation
WARNING  → Approaching constraint boundary
CAUTION  → Within safety margin
ALERT    → Immediate action required
CRITICAL → Emergency shutdown initiated

The test suite verifies these guardrails:

[Envelope (PBAS-6 Guardrails) Tests]
  envelope_initial... PASS
  envelope_check... PASS
  envelope_escalation... PASS
  guard_state_string... PASS

This integration means MycoEco doesn’t just provide deterministic execution—it provides safe deterministic execution with runtime verification.

Kernel Size: Under 256KB

One of MycoEco’s notable properties is its size. The entire kernel—multi-core scheduling, event management, replay capability, cryptographic hashing, PBAS-6 guardrails—fits in under 256KB of memory.

[ABI Tests]
  abi_event_size... PASS
  abi_envelope_size... PASS
  abi_kernel_under_256k... PASS

For comparison:

• Linux kernel: ~30MB (minimal configuration)
• FreeRTOS: ~10KB (but without deterministic multi-core, crypto, or guardrails)
• seL4 (microkernel): ~12KB (but without multi-core determinism)

MycoEco achieves substantial functionality in a compact footprint. This makes it viable for:

• Aerospace applications with strict memory budgets
• Medical devices where certification effort scales with code size
• Automotive ECUs with limited flash memory
• IoT devices requiring deterministic behaviour

The Certification Consideration

Safety certification (DO-178C, ISO 26262, IEC 62304) requires significant effort. Effort tends to scale with:

• Lines of code (more code = more testing)
• Complexity (locks and race conditions require extensive analysis)
• Timing variability (may require probabilistic analysis and larger test suites)

MycoEco’s architecture can address all three:

Small codebase: Under 256KB means fewer lines to verify

Simpler semantics: Event-based architecture can be easier to reason about than lock-based concurrency

Deterministic execution: Can reduce or constrain classes of timing-related failure modes that require probabilistic analysis

This architectural approach may support reduced certification effort compared to conventional RTOS with locks, though actual impact depends on specific system requirements and regulatory context.

Architectural Implications

Many existing systems have been designed under assumptions that prioritise either determinism or scalability. MycoEco demonstrates that these goals need not be mutually exclusive.

This has potential implications for several domains:

Autonomous systems: Can potentially achieve real-time performance with deterministic guarantees, supporting certification of control systems.

Medical devices: Can leverage multi-core processors while maintaining the determinism that supports regulatory approval.

Aerospace: Can use commercial multi-core processors in safety-critical avionics while maintaining determinism.

Industrial control: Can pursue both high performance and high safety integrity levels.

Conclusion

MycoEco demonstrates that deterministic, lock-free multi-core execution is achievable within a compact, certifiable kernel architecture.

Through event-based architecture, deterministic scheduling, and lock-free coordination, MycoEco provides:

• Deterministic execution across multiple cores
• Replay capability for execution verification
• Bounded real-time characteristics
• Safety envelopes via PBAS-6 integration
• Minimal footprint (< 256KB)
• Certification-friendly architecture

The test suite passes 46 tests including multi-core replay verification. The kernel scales efficiently within its design parameters. The architecture supports certification to high safety standards.

For organisations building safety-critical systems, MycoEco provides an additional architectural option when balancing performance, predictability, and verification effort.

Internal test output summarises the result of deterministic multi-core replay verification:

Deterministic multi-core execution verified under test conditions.