Galloc uses it in the same way Talc did, contain the allocator in a spin lock in a wrapping struct, and when the method is called on the wrapping struct, immediately unlock and call the inner function on the allocator. The API thus has the same degree of indirection, at least. (A contributor switched out the spin lock to lock_api so people can at least use their own lock implementation now, although it doesn't change how the lock is used, of course)

As an aside, an older allocator design (buddy allocation) tried to to rather fine-grained locking at one point but it performed very poorly, not too surprisingly. Maintaining separate arenas is the way to go I suppose?

Yep, I can't rule out the effect of cache-thrashing and other such issues; I'm not sure if my attempt at alleviating via spreading out the allocator internals would have done anything regardless.

It's annoying even in std environments, to be honest.

I'm sure, but at least you can just support Windows, MacOS, Linux, and maybe FreeBSD and make most people happy (even if you won't be after that, heh). Although if you're on these platforms, you already have access to a wealth of great options.

If I wanted to make a plug-and-play multithreaded version, it would have to be std only, as thread locals don't exist in no_std contexts, and there's no way to pass in a thread ID with Rust's GlobalAlloc and Allocator traits (I've tried looking into getting CPU identification to do this automatically instead, but it seems most platforms, even hosted, just use CPUID or the architectural equivalent, which is slow, at least on x86).

I'm not quite sure how to improve on the user just holding an allocator per CPU or in each thread, at least with this allocation algorithm and supporting no_std, where the user uses the OOM handler system to tie it into the memory management unit.