[lockfree] tagged_ptr as a separate library
In the review of lockfree it has been suggested that tagged_ptr should make it into the public API of lockfree. Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself. Philipp Moeller
In the review of lockfree it has been suggested that tagged_ptr should make it into the public API of lockfree.
Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself.
for now i prefer to keep it an implementation detail. but maybe it can be exposed to the public API in future. how now i'd like to wait until there are some std::atomic implementation which can actually compile the tagged_ptr. i hope boost.lockfree will be in 1.50, still waiting for boost.atomic, though ... cheers, tim
Tim Blechmann <tim@klingt.org> writes:
In the review of lockfree it has been suggested that tagged_ptr should make it into the public API of lockfree.
Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself.
for now i prefer to keep it an implementation detail. but maybe it can be exposed to the public API in future. how now i'd like to wait until there are some std::atomic implementation which can actually compile the tagged_ptr. i hope boost.lockfree will be in 1.50, still waiting for boost.atomic, though
Isn't tagged_ptr also useful even when it is not used atomically? Sorry, for the mix-up of the delays. I was under the (wrong) impression that boost.atomic is waiting for boost.lockfree.
cheers, tim
Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself.
for now i prefer to keep it an implementation detail. but maybe it can be exposed to the public API in future. how now i'd like to wait until there are some std::atomic implementation which can actually compile the tagged_ptr. i hope boost.lockfree will be in 1.50, still waiting for boost.atomic, though Isn't tagged_ptr also useful even when it is not used atomically?
i've personally not seen any use case for a tagged pointer except for prevention of the ABA problem. especially the pointer-compression is mainly to pack pointer and tag into a 64bit memory region, which is mainly required for systems without 128bit compare-and-swap ...
Isn't tagged_ptr also useful even when it is not used atomically?
i've personally not seen any use case for a tagged pointer except for prevention of the ABA problem. especially the pointer-compression is mainly to pack pointer and tag into a 64bit memory region, which is mainly required for systems without 128bit compare-and-swap ...
I've heard of the JVM running in 64bit memory model, but compressing pointers into 32bits by taking advantage of word alignment and most of the address space starting around 0. It means they can access ~32GB memory while not having the memory footprint of all pointers double. UseCompressedOops http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom... The assumptions you need for your tagged pointer sound about the same. I could also imagine someone using 16-bit pointers to keep dynamic data structures in 64kB of LD1 cache. Chris
Isn't tagged_ptr also useful even when it is not used atomically?
i've personally not seen any use case for a tagged pointer except for prevention of the ABA problem. especially the pointer-compression is mainly to pack pointer and tag into a 64bit memory region, which is mainly required for systems without 128bit compare-and-swap ...
I've heard of the JVM running in 64bit memory model, but compressing pointers into 32bits by taking advantage of word alignment and most of the address space starting around 0. It means they can access ~32GB memory while not having the memory footprint of all pointers double. UseCompressedOops http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom...
i suppose the main difference is that c++ runs on a real machine, while java runs on a virtual machine?
The assumptions you need for your tagged pointer sound about the same.
I could also imagine someone using 16-bit pointers to keep dynamic data structures in 64kB of LD1 cache.
in a way this converts pointers to indices ... i am using this technique under certain circumstances, but it does not work for dynamically growing data structures ... tim
On Thu, Apr 12, 2012 at 6:08 PM, Tim Blechmann <tim@klingt.org> wrote:
I've heard of the JVM running in 64bit memory model, but compressing pointers into 32bits by taking advantage of word alignment and most of the address space starting around 0. It means they can access ~32GB memory while not having the memory footprint of all pointers double. UseCompressedOops
http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom...
i suppose the main difference is that c++ runs on a real machine, while java runs on a virtual machine?
It could work on real hardware too if the OS supports it. Olaf
On 30 Mar 2012, at 14:21, Tim Blechmann wrote:
Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself.
for now i prefer to keep it an implementation detail. but maybe it can be exposed to the public API in future. how now i'd like to wait until there are some std::atomic implementation which can actually compile the tagged_ptr. i hope boost.lockfree will be in 1.50, still waiting for boost.atomic, though Isn't tagged_ptr also useful even when it is not used atomically?
i've personally not seen any use case for a tagged pointer except for prevention of the ABA problem. especially the pointer-compression is mainly to pack pointer and tag into a 64bit memory region, which is mainly required for systems without 128bit compare-and-swap ...
Tagged pointers are also useful for implementing implementing union-like types. I personally use a variant_ptr type, which on 64-bit systems uses tags to store the type of the variant, rather than requiring an extra int to be allocated in the variant object. Tagged pointers are also useful as a basis for things like the small-string optimisation, storing a value in a pointer. I'm not sure if I would start building such a thing on a tagged pointer however. Perhaps if I already had one to hand. Chris
participants (5)
-
Christopher Jefferson -
Hite, Christopher -
Olaf van der Spek -
Philipp Moeller -
Tim Blechmann