Ruling out arbitrary cost copy construction?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Thu Nov 4 12:32:51 PDT 2010


On 11/4/10 2:06 PM, dsimcha wrote:
> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
>> 2. Each destructor should be called in the thread that created the object.
>> The second solution is quite attractive. It can be implemented by
>> associating each thread with a worklist - a list of objects to destroy.
>> The GC can run in any thread but it will not call destructors. Instead,
>> it adds objects to be destroyed to the threads that created them (this
>> means we need to add a field to each object with the thread ID of the
>> creating thread). When client code calls new, the allocation routine
>> will first inspect the worklist and call the destructors if needed.
>> I think this can be made to work and has good properties, although a
>> fair amount of details need to be figured out. Please share any thoughts
>> you may have.
>> Andrei
>
> Interesting, though I feel like the baseline cruft for Object is getting a little
> big.  I think we could store the thread ID and the monitor object in the same
> memory.  If a class is being synchronized on, then it's shared rather than being
> owned by a single thread.  Therefore, at an offset of 1, a class either has a
> pointer to a monitor (if it's shared, and therefore can be destroyed in any
> thread) or a thread ID (if it's unshared).  To tell them apart, just see if the
> classinfo pointer points to a Monitor or a Thread.

Yah, my thoughts exactly. My feeling is that this is one of those areas 
where it's difficult to find a solution that's at the same time simple 
and good.

Sean, any thoughts?

Andrei


More information about the Digitalmars-d mailing list