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