An important pull request: accessing shared affix for immutable data

[Dicebot via Digitalmars-d]

On 02/12/2016 09:12 PM, Andrei Alexandrescu wrote:
> 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.

Thank you for moving forward with this. I haven't yet had chance to play
with the code but it looks like a good start. Some minor notes on
implementation (I have also discussed it a bit with deadalnix in IRC):

- cache thrashing for shared allocations can be reduced by aligning
those on cache line size (for thread-local ones it is not needed)
- considering this API is going to be dangerously @system, possible
corruption of metadata is indeed very scary - though not a blocker
within my own value list
- I wonder if would make for a cleaner design to have distinct allocator
instances for thread-local and shared memory instead of branching on
qualifiers of requested type

Right now the main concern to me is how such design is going to interact
with existing code like `assumeUnique`. With GC which treats all memory
similarly it is legal (and somewhat common) to allocate mutable
non-shared data first and only later cook it into immutable via
`assumeUnique`. But if allocator has to treat such memory differently
(i.e. add barriers/atomics  for non-TLS one) such code will start
silently introduce major bugs.

Sadly, don't have any specific suggeestions about all of this yet.