On 2012-10-18 18:26:08 +0000, Sean Kelly <[email protected]> said:
Well, the problem is more that a variable can be cast to shared after
instantiation, so to allow thread-local collections we'd have to make
cast(shared) set a flag on the memory block to indicate that it's
shared, and vice-versa for unshared. Then when a thread terminates, all
blocks not flagged as shared would be finalized, leaving the shared
blocks alone. Then any pool from the terminated thread containing a
shared block would have to be merged into the global heap instead of
released to the OS.
I think we need to head in this direction anyway, because we need to
make sure that thread-local data is finalized by its owner thread. A
blocks owner would be whoever allocated the block or if cast to shared
and back to unshared, whichever thread most recently cast the block back
to unshared. Tracking the owner of a block gives us the shared state
implicitly, making thread-local collections possible. Who wants to work
on this? :-)
All this is nice, but what is the owner thread for immutable data?
Because immutable is always implicitly shared, all your strings and
everything else that is immutable is thus "shared" and must be tracked
by the global heap's collector and can never be handled by a
thread-local collector. Even if most immutable data never leaves the
thread it was allocated in, there's no way you can know.
I don't think per-thread GCs will work very well without support for
immutable data, an for that you need to have a distinction between
immutable and shared immutable (just like you have with mutable data).
I complained about this almost three years ago when the semantics of
shared were being defined, but it got nowhere. Quoting Walter at the
time:
As for a shared gc vs thread local gc, I just see an awful lot of
strange irreproducible bugs when someone passes data from one to the
other. I doubt it's worth it, unless it can be done with compiler
guarantees, which seem doubtful.
I think you'll have a hard time convincing Walter it is worth changing
the behaviour of type modifiers at this point.
Reference:
<http://lists.puremagic.com/pipermail/dmd-concurrency/2010-January/000132.html>
<http://lists.puremagic.com/pipermail/dmd-concurrency/2010-January/000146.html>
--
Michel Fortin
[email protected]
http://michelf.ca/
