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
