Sharing in D

[Sean Kelly]

Don wrote:
> 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.
> 
> Would this be an end to 'static' variables?

I think that's the only feasible option for D1, which is why I'm 
hesitant to pursue per-thread GCs.  It's a restriction that would have 
no language support but rather rely on convention to prevent crashes.

For D2 I think it may be possible to rely on the transitivity of 
'shared' and to use this type qualifier to allocate from a central "stop 
the world" GC.  The tricky thing here is that local data would have to 
be copied if it were to be referenced only from the shared area, similar 
to an .idup I suppose.


Sean