search

hawkw / sharded-slab

a lock-free concurrent slab (experimental)
MIT License
269 stars 17 forks source link

#![no_std] support #76

Open AppCoder1234 opened 1 year ago

AppCoder1234 commented 1 year ago

Hi, Do you know if you plan for no_std support? It would be really helpful, because I'm precisely looking for a lock-free, no_std slab storage Looking at your crate, it does not seem like you use a lot of std-only features, I would venture saying maybe only no_std + alloc would be sufficient, and it would not be much overhead going no_std (I just don't know for the std::thread::panicking in panic_in_drop) I can possibly help for the commit to support no_std What do you think?

hawkw commented 1 year ago

Unfortunately, the sharding scheme this library uses relies on assigning an ID to each thread spawned by a program. This is implemented using a thread-local variable: https://github.com/hawkw/sharded-slab/blob/8ebe120fd28b3a463932bbf0728e2baf5a558840/src/tid.rs#L40-L42

Because threads are an abstraction provided by an operating system, there is no portable way to determine what concurrency context (e.g. CPU core) a slab is accessed in without using the standard library.

I would really like to be able to provide a version of this library that does support no-std uses. I think the way we would do this is by providing an abstraction for determining the current "concurrency context" (e.g. thread or CPU core). By default, this would be implemented to return the ID of the current thread. However, bare-metal users could provide an implementation of this interface that identifies a CPU core number or similar, using platform-specific features of the hardware they're targeting. This interface would, of course, be unsafe to implement, because an incorrect implementation could result in the same shard being mutated concurrently --- the library would rely on the implementation ensuring that each concurrency context always returns a unique ID.

Designing something like this would require some work, and I haven't really had the time to work on it. However, it is probably possible.

AppCoder1234 commented 1 year ago

Ok thanks for the quick and detailed reply, I thought it would have been simpler Do you know if there is any crate near the "concurrency context" abstraction that you mention in the crate ecosystem? Maybe I can look at implementing something like that (a PID trait/interface), although I can't promise anything and would probably need some help/feedback along the way Btw, do you want this issue to be closed?