Ruling out arbitrary cost copy construction?

[Michel Fortin]

On 2010-10-31 12:39:10 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 10/31/10 5:40 AM, Michel Fortin wrote:
>> I'm not opposed to the idea of ruling out arbitrary-cost postblits, but
>> I fear it might be futile. If std::string is any indication, COW doesn't
>> scale well with multithreading. There is a way to make COW efficient for
>> thread-local objects in the GC-heap, but that would require thread-local
>> GC heaps, and this has been ruled out in the design of 'shared' and
>> 'immutable'.
> 
> D's approach to concurrency is predicated by distinguishing shared data 
> from unshared data statically (by means of the shared qualifier).

Yes, and that was a very good idea.


> As such, unshared types can always use non-atomic reference count 
> manipulation in confidence that there is no undue sharing going on.

And it works, except in a destructor when that destructor is called by 
the GC (because the GC can call a destructor from another thread). The 
discussion of 4621 shows that the compiler can't detect the races that 
might arise if you dereference a member in a destructor. If the 
compiler could be made to prevent those races, all instances of bug 
4624 would be caught at compile-time and you'd have to either:

1. use a shared reference counter with atomic operations (and possibly 
cast your way around), or
2. restrict those structs to the stack and non-GC allocated memory.

That's the conclusion from the discussion of bug 4621. A third way 
would be to make the GC call a destructor in the thread that owns the 
memory block, but how should the GC determine which thread owns which 
block? Is memory always owned by the thread that allocated it? And does 
that mean the destructor will be postponed until that thread asks for a 
new memory allocation? Perhaps that's what we should do.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/