Shared keyword and the GC?

Alex Rønne Petersen alex at lycus.org
Thu Oct 18 23:56:11 PDT 2012


On 18-10-2012 20:26, Sean Kelly wrote:
> On Oct 17, 2012, at 1:55 AM, Alex Rønne Petersen <alex at lycus.org> 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
alex at lycus.org
http://lycus.org


More information about the Digitalmars-d mailing list