C
Chris Thomasson
[comp.lang.c++ added because its going to standardize fine-grain, very
low-level multi-threading primitives; refer cpp-threads mailing list...]
I decoupled the allocation logic from the synchronization mechanism such
that single-threaded allocators can now be used in full-blown multi-threaded
environments. IMHO, it's a really neat feature. You could even set things up
where a thread A uses a different allocator than thread B, yet they are
still able to allocate; pass around and free blocks between themselves. Its
an extremely flexible framework.
This can be an important invention. Here is the basic sales pitch:
Question: How do you create a multi-threaded allocator, without creating a
multi-threaded allocator?
Answer: Create a single-threaded allocator and tell the vZOOM library to
multi-thread it for you...
Wow! :^)
Here is the "basic" vZOOM allocation scheme:
________________________
- create a thread-local instance of a user-defined single-threaded
allocator in every thread (e.g., ms heap w/ HEAP_NO_SERIALIZE).
- allocation requests are forwarded to this thread-local user allocator
directly.
- if free request goes from thread that allocated block (e.g., the origin
thread), then free request is forwarded to this thread-local user allocator.
- if free request goes from another thread, then you accumulate this block
in per-thread stack-based freelist "belonging to the origin thread", using
single atomic CAS.
- blocks from this freelist is actually reused/freed in batches using
single atomic SWAP when thread allocates/deallocates another block. For
instance, a thread that fails to allocate from its thread-local heap will do
a SWAP on the freelist and try and fulfill the allocation request from
there.
________________________
Any thoughts/comments/suggestions/rants/raves?
;^)
low-level multi-threading primitives; refer cpp-threads mailing list...]
I decoupled the allocation logic from the synchronization mechanism such
that single-threaded allocators can now be used in full-blown multi-threaded
environments. IMHO, it's a really neat feature. You could even set things up
where a thread A uses a different allocator than thread B, yet they are
still able to allocate; pass around and free blocks between themselves. Its
an extremely flexible framework.
This can be an important invention. Here is the basic sales pitch:
Question: How do you create a multi-threaded allocator, without creating a
multi-threaded allocator?
Answer: Create a single-threaded allocator and tell the vZOOM library to
multi-thread it for you...
Wow! :^)
Here is the "basic" vZOOM allocation scheme:
________________________
- create a thread-local instance of a user-defined single-threaded
allocator in every thread (e.g., ms heap w/ HEAP_NO_SERIALIZE).
- allocation requests are forwarded to this thread-local user allocator
directly.
- if free request goes from thread that allocated block (e.g., the origin
thread), then free request is forwarded to this thread-local user allocator.
- if free request goes from another thread, then you accumulate this block
in per-thread stack-based freelist "belonging to the origin thread", using
single atomic CAS.
- blocks from this freelist is actually reused/freed in batches using
single atomic SWAP when thread allocates/deallocates another block. For
instance, a thread that fails to allocate from its thread-local heap will do
a SWAP on the freelist and try and fulfill the allocation request from
there.
________________________
Any thoughts/comments/suggestions/rants/raves?
;^)