An important pull request: accessing shared affix for immutable data

[Timon Gehr via Digitalmars-d]

On 12.02.2016 20:12, Andrei Alexandrescu wrote:
> https://github.com/D-Programming-Language/phobos/pull/3991
>
> A short while ago Dicebot discussed the notion of using the allocator to
> store the reference count of objects (and generally metadata). The
> allocator seems to be a good place because in a way it's a source of
> "ground truth" - no matter how data is qualified, it originated as
> untyped mutable bytes from the allocator.
>
> So after thinking a bit I managed to convince myself that the affixes in
> an AffixAllocator can be accessed with removing immutable, but without
> actually breaking any guarantee made by the type system. (Affixes are
> extra bytes allocated before and after the actual allocation.) The logic
> goes as follows:
>
> * If the buffer is mutable, then the allocator assumes it hasn't been
> shared across threads, so it returns a reference to a mutable affix.
>
> * If the buffer is const, then the allocator must conservatively assume
> it might have been immutable and subsequently shared among threads.
> Therefore, several threads may request the affix of the same buffer
> simultaneously. So it returns a reference to a shared affix.
>
> * If the buffer is shared, then the allocator assumes again several
> threads may access the affix so it returns a reference to a shared affix.
>
> One simple way to look at this is: the allocator keeps an associative
> array mapping allocated buffers to metadata (e.g. reference counts). The
> allocated buffers may be immutable, which doesn't require the metadata
> to be immutable as well. The only difference between an approach based
> on an associative array and AffixAllocator is that the latter is faster
> (the association is fixed by layout).
>
>
> Destroy!
>
> Andrei
>

The first thing that comes to mind is that accessing a global 
associative array is not 'pure'.