A few thoughts on std.allocator

[Steven Schveighoffer via Digitalmars-d]

On 5/13/15 1:35 AM, Dicebot wrote:
> On Tuesday, 12 May 2015 at 17:21:04 UTC, Steven Schveighoffer wrote:
>> The one that always comes to my mind is array appending:
>>
>> immutable int[] x = new int[5];
>>
>> const int[] y = x;
>>
>> x ~= 1; // should this lock;
>>
>> y ~= 1; // should this lock?
>
> As per my udnerstanding `shared` should _never_ result in automatic
> locking or barriers or whatever. It is simply a tag qualfier, with no
> extra magical semantics.

It's not automatic, the runtime does it.

It uses the type information to determine whether it needs to lock or 
not. It also avoids the thread-local Most Recently Used cache to look up 
block info, since that may not be accurate. Essentially, the *lack* of 
shared can be used to optimize in the runtime.

Right now, it assumes that const does not mean shared, but that can 
cause issues if you had a shared immutable array that you were appending 
to via a const reference. The logic for not locking there is that the 
vast VAST majority of cases do not have this problem.

-Steve