Sharing in D

[Sean Kelly]

== Quote from downs (default_357-line at yahoo.de)'s article
> Walter Bright wrote:
> > downs wrote:
> >> I am looking for a safe way to transfer ownership of a single object
> >> between threads.
> >>
> >> Like, for instance, a "unique Object foo" would behave like a shared
> >> Object, but the compiler would treat it like a nonshared object for
> >> purposes of optimization, and all accesses from the outside would be
> >> implicitly synchronized.
> >>
> >> This could be used for objects that really are only supposed to exist
> >> once, but still used in a multithreaded way.
> >>
> >> Hope that clears things up.
> >
> > Sorry, I still have no idea what you're asking for.
> Okay.
> In the current system, every object "belongs" to every thread equally -
synchronization blocks are used to prevent interference.
> In the new system, this behavior, if I understand correctly, is equivalent to
"shared".
> The default, non-shared, would be objects that belong, permanently, to exactly
one thread - the one that created them, to the extent that accessing them from
another thread would constitute a compiler failure.
> What I am looking for, then, is to somehow temporarily, or permanently, change
the thread that a specific instance belongs to, transfer ownership to another
thread, so to speak, in an atomic manner - so that at no time more than one thread
possesses ownership of the object - thus gaining, basically, the guaranteed
thread-safety of a non-shared object with the convenience of a shared object.

We've discussed creating per-thread GCs in Tango to eliminate the
problem of "stop the world" collections.  Transferral of ownership
is complicated with such a model, however, if the object being
transferred represents a resource.  Everything else you can just
.dup (ie. perform a deep copy), but obviously not singletons.  I'd
be inclined to say that this is a limitation you'll just have to
deal with when designing your program.  Make one thread the "owner"
of the object and have other threads interact with it basically via
messaging.

This idea of per-thread GCs dovetails perfectly with 'shared' as
well, since there's no way in D 1.0 to flag the creation of static
data.  In D 2.0 however, it sounds like all such data either must
be labeled 'shared' or can be made thread-local as well.  Totally
awesome.  Of course, that still means that memory backing shared
data will leak in the absence of a GC, so either this would have
to be stated and the user would have to deal with it, or there
would still need to be a global "stop the world" GC specifically
for the shared data.  In the latter case, I'd probably default the
GC to disabled so the user would either collect manually or enable
it if he doesn't care about an occasional "stop the world" collection.


Sean