I think we need some more description here about the locklessness:
How about adding to the comment:
This version of the allocator supports lockless operation.
This makes it safe to use in NMI handlers and other special unblockable
contexts that could otherwise deadlock on locks. This is implemented by
using atomic operations and retries on any conflicts.
The disadvantage is that there may be livelocks in extreme cases.
The lockless operation only works if there is enough memory
available. If new memory is added to the pool a lock has to
be still taken. So any user relying on locklessness has to ensure
that sufficient memory is preallocated.
The basic atomic operation of this allocator is cmpxchg on long.
On architectures that don't support cmpxchg natively a fallback
is used. If the fallback uses locks it may not be safe to use
it in NMI contexts on these architectures.
I believe that's not safe in a lockless context right?
Should note that.
email@example.com -- Speaking for myself only.