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.