Sharing in D

[JAnderson]

Sean Kelly wrote:
> == 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

Some good points.

One thing that will likely happen with shared GC is that there will be 
relativity a very small amount of shared memory needed.  Therefore GC 
collection on the shared memory might be fast enough for many people.

If there's a lot of memory being shared its a sign that something might 
be wrong.  That's because a huge amount of shared memory means that the 
benefit of multi-threading will seriously be diminished.  Also maybe 
"shared" could eventually use a different kinda GC which is more optimal 
for shared memory.  If there was a way to say which threads had 
read/write (or both) access to different shared memories then not all 
threads would need to be stopped.

-Joel