On 18-10-2012 20:26, Sean Kelly wrote:
On Oct 17, 2012, at 1:55 AM, Alex Rønne Petersen <[email protected]> wrote:
So, let's look at D:
1. We have global variables.
1. Only std.concurrency enforces isolation at a type system level; it's not
built into the language, so the GC cannot make assumptions.
1. The shared qualifier effectively allows pointers from one thread's heap into
another's.
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? :-)
I'm not really sure how this solves the problem of having pointers from
a thread-local heap into the global heap and vice versa. Can you
elaborate on that?
The problem is that even if you know whether a piece of memory is
flagged shared, you cannot know if some arbitrary number of threads
happen to have pointers to it and can thus mutate anything inside it
while a thread-local collection is in progress.
--
Alex Rønne Petersen
[email protected]
http://lycus.org
