On 13.05.2014 13:09, "Marc Schütz" <[email protected]>" wrote:
On Tuesday, 13 May 2014 at 06:06:40 UTC, Rainer Schuetze wrote:
On 12.05.2014 13:53, "Marc Schütz" <[email protected]>" wrote:
I'm surprised that you didn't include:
3. Thread-local GC, isolated zones (restricting where references to
objects of a particular heap can be placed), exempting certain threads
from GC completely, ...
This comes up from time to time, but to me it is very blurry how this
can work in reality.
Considering how "shared" is supposed to be used to be useful (do some
locking, then cast away "shared") there is no guarantee by the
language that any object is actually thread local (no references from
other threads). Working with immutable (e.g. strings) is shared by
design.
Yes, but only a part of the data is shared. I suspect the majority of
the data in typical programs will be thread-local. If you use a message
passing model, you can improve that even further (though it requires a
way to move an object to another thread's heap). This way, you can - in
the best case - avoid the shared heap completely.
Possible, but this is with a language without shared data (including
immutable), not D. Safely transferring a large object tree from one
thread to another will be very expensive. If you try to optimize that,
the D compiler won't help you to guarantee memory safety.
Actually I don't have much experience with "shared" (I usually use
__gshared if I need a shared global). Maybe I understand the idea better
if you show what happens with this code when run with thread local GC:
class C { C next; }
shared(C) list;
C newC()
{
return new C; // allocated on the local heap?
}
void prependToList(C c)
{
synchronized(list)
{
C lst = cast(C) list;
c.next = lst; // anything special happening here?
list = cast(shared(C)) c; // and here?
}
}
void callMeFromMultipleThreads()
{
prependToList(newC());
}