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