Ruling out arbitrary cost copy construction?

Steven Schveighoffer schveiguy at yahoo.com
Thu Oct 7 06:39:08 PDT 2010


On Wed, 06 Oct 2010 16:19:45 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 10/6/10 14:09 CDT, Michel Fortin wrote:
>> On 2010-10-06 12:34:54 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> 2. It would force certain types (such as BigInt) that allocate
>>> resources and have value semantics to resort to reference counting.
>>
>> Also, before asking for more reference counting, perhaps you should
>> check that bug and find a nice way to do reference counting correctly
>> with no race conditions (unlike what's done in Phobos currently).
>> <http://d.puremagic.com/issues/show_bug.cgi?id=4624>
>
> I'm not sure the bug report is valid, but I agree it's a matter to look  
> into.

It is valid.  When you use GC-allocated memory in a destructor, it's bad  
news.  And structs that are members of classes can have their destructors  
called from the GC.

>> The most problematic thing with reference-counted memory is that the GC
>> can call your struct's destructor from any thread which can cause
>> low-level races if the reference counter isn't manipulated with atomic
>> operations. And atomic operations slow things down, are you sure you
>> want to force this in BigInt?
>
> The GC shouldn't be able to destroy things naively concurrently with  
> other threads. Currently all threads are frozen; I'm not sure whether a  
> frozen thread commits its writes, so that needs to be verified.

I think Michel is right.  Let's say thread A is copying a File struct to  
the stack, and is on this line:


     this(this)
     {
         if (!p) return;
         assert(p.refs);
>       ++p.refs;
     }

And thread B is allocating memory.  This triggers a GC collection cycle,  
and in the heap is a class object which contains the same File struct as a  
member.  That File's destructor is called, and
--refs is called.  Note that the object being destroyed does not have to  
be shared. This is a classic race.

-Steve


More information about the Digitalmars-d mailing list