A few thoughts on std.allocator

[Jonathan M Davis via Digitalmars-d]

On Sunday, 10 May 2015 at 09:50:00 UTC, Andrei Alexandrescu wrote:
> 3. Thread-local vs. shared objects
>
> Currently in D it's legal to allocate memory in one thread and 
> deallocate it in another. (One simple way to look at it is 
> casting to shared.) This has a large performance cost that only 
> benefits very few actual cases.
>
> It follows that we need to change the notion that you first 
> allocate memory and then brand it as shared. The "will be 
> shared" knowledge must be present during allocation, and use 
> different methods of allocation for the two cases.

As long as casting to or from shared really doesn't do anything 
other than change how the type system treats that type, we can't 
really assume much of anything with regards to where shared _or_ 
thread-local variables came from. Maybe it's still of benefit for 
the allocator to know that it's going to be dealing with shared 
as opposed to thread-local variables when doing the allocation, 
but I don't see how we can get rid of the possibility of an 
object being allocated on one thread and deallocated on another 
without making major changes to shared - and std.concurrency 
isn't going to work very well if we can't cast to and from shared 
or immutable to pass objects across threads - not unless we add 
some way to indicate in the type system that a variable is being 
passed across threads.

It may very well be that we _need_ to change how shared is 
treated by the language and runtime and how its plumbing works, 
but as it stands, I don't see how we could possibly assume that 
whether an object is created as shared or thread-local - or even 
what thread it's created on - has much of anything to do with how 
it's _actually_ going to be used. In _most_ cases, an object is 
going to be used on the same thread that it's created on, and if 
it were possible to create an object as shared directly (which it 
usually isn't), then in most cases an object that was created as 
thread-local would be destroyed on the thread that it's created 
on, and an object created as shared would be used as shared and 
destroy on who-knows-which thread, but because of both the 
possibility and need to cast to and from shared to do anything 
useful with shared as well as passing objects across threads, we 
simply cannot assume anything about how an object will be used 
based on whether it's constructed as shared or not or which 
thread it's constructed on.

For any of that to change, shared needs to change.

- Jonathan M Davis