|
Boost : |
Subject: Re: [boost] interest in a stateful pointer library?
From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2017-10-09 15:12:56
Hi Arvid,
> On 9. Oct 2017, at 12:59, Arvid Norberg via Boost <boost_at_[hidden]> wrote:
>
> Without having read the reddit thread, I would expect this library to only
> depend on *implementation defined* behavior. Namely the mapping of pointer
> to integer conversions [1].
>
> A pointer can be explicitly converted to any integral type large enough to
>> hold it. The mapping function is implementation-defined.
>
> [ Note: It is intended to be unsurprising to those who know the addressing
>> structure of the underlying machine. â end note]
>
> That note seem to indicate that only in the case of exotic hardware would
> the assumptions about what aligned addresses look like be invalid.
yes, that was also the conclusion in the Reddit thread, thank you for clarifying this.
We cannot know whether the library might be used on exotic hardware, right? Then we would need a fallback solution which relies only on standard behavior for such a platform. The question is what kind of fallback solution one could offer. If the library does not guarantee that tagged_ptr always has the size of void*, then one could fall back to something like this
template <typename T, unsigned Nbits>
struct tagged_ptr_fallback {
T* ptr;
[smallest integral type that can hold Nbits] bits;
};
There is already a hidden tagged_ptr in Boost, see lockfree/detail/tagged_ptr.hpp, which uses this kind of fallback. The bit-harvesting there follows a different approach, btw. which is relies on details of the x86_64 hardware and only works there. I am not an expert, but I think it exploits that some part of the address space is reserved for the kernel. This actually has advantages over my approach of using aligned memory; the number of harvested bits is quite large and it works with any allocator. I just thought that the trick of using aligned memory would work on more platforms.
Best regards,
Hans
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk