Crates.io | slaballoc |
lib.rs | slaballoc |
version | |
source | src |
created_at | 2021-07-31 17:22:50.883172 |
updated_at | 2024-09-29 17:13:15.901109 |
description | Safe and lockless fixed-size memory allocator for `no_std` systems |
homepage | |
repository | https://github.com/DrChat/slaballoc |
max_upload_size | |
id | 429773 |
Cargo.toml error: | TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
no-std
compatible, thread-safe fixed-size memory allocatorDo you need to allocate objects of a single type on a bare-metal system using #[no_std]
?
Do you have the requirement that an allocator be concurrently accessed from multiple
threads or CPU cores?
Look no further!
This crate provides a lockless no_std
compatible slab allocator, for fixed-size
allocations.
This slab allocator takes a fixed-size block of memory, as well as a [Sized] type for allocations. The slab allocator will partition the block of memory into two parts: an area for allocated objects, and an area for an allocation bitmap.
The bitmap will have a bit size of mem_size / size_of::<T>()
, such that there
is a bit for every possible slot that an object can take.
So, for a 4096 byte block of memory and objects that are 16 bytes each, the
bitmap will take 256 bits, or 32 bytes.
| objects........................................ - bitmap |
Note that the bitmap will be a little larger than necessary because it accounts for the entire block of memory (including the part that it takes up). This can be accounted for, but it's an annoying self-dependency so it'll take some iterations.
The allocation bitmap can then be accessed locklessly using atomic intrinsics. When allocating, we'll simply set a bit in the bitmap, and if successful, return the memory corresponding to that bit. When deallocating, we can simply unset the bit and the memory is freed.
If you're using Rust on a hosted environment with std
available, you might
be interested in using sharded-slab instead. That crate gets you the same
semantics as this one, without having to used a fixed-size memory block.