Theseus
Theseus copied to clipboard
theseus-os
Use lock-free heap allocator
Heap allocations are horribly expensive right now because the Heap acquires an Irq-safe Mutex lock, which disables interrupts for the duration of a heap allocation.
We should switch to a lock-free implementation of the heap, such that interrupts can remain enabled.
Instead of a lock-free allocator, which is likely impossible, I think a better solution is to use a separate allocator for allocations that occur in interrupt contexts. This is now possible with Rust's new allocator_api feature that allows you to allocate something using a specific allocator rather than just the global default.
https://github.com/rust-lang/rust/issues/32838
For example, we can use Box::new_in(object, InterruptSafeAllocator) instead of just Box::new(obj). See this: https://doc.rust-lang.org/alloc/boxed/struct.Box.html#method.new_in
Instead of a lock-free allocator, which is likely impossible,
why is lock-free allocator likely impossible?
Heap allocations are horribly expensive right now because the Heap acquires an Irq-safe Mutex lock, which disables interrupts for the duration of a heap allocation.
The root issue we're trying to solve is to make the heap allocations use resources more efficiently. Can we break down the resource usage of the heap allocations into all the different cases/categories? Perhaps doing so may help us identify bottlenecks
IRQ safety (disabling interrupts) exists for a reason: it prevent race conditions in case two interrupt handlers try to access the same resource. This kind of memory safety is one of the main reasons we're introducing TheseusOS as a better alternative to OS:es based on C/C++. Ideally, we should identify when the interrupt disabling is needed and when it's not needed. That way, we can apply the interrupt disabling in cases where it's needed to prevent race conditions, while avoiding unnecessary resource waste outside of those cases (the number of interrupt handlers able to access CPU can be viewed as a resource).
The key question we need to answer is:
- [ ] When does IRQ-unsafe heap allocation risk race conditions?
