[D-runtime] Precise garbage collection

[Rainer Schuetze]

On 23.06.2013 04:07, Jonathan M Davis wrote:
> On Saturday, June 22, 2013 18:48:46 Steven Schveighoffer wrote:
>> If you cast away shared, but don't ensure the data becomes actually
>> unshared, you are in bad territory too.
>
[...]
> At this point, I'd be very nervous about anything in the runtime assuming that
> a non-shared object won't be used across threads. It should be able to assume
> that it's not _currently_ being used across threads (since it _is_ up to the
> programmer to ensure that they don't violate the type system by having
> multiple threads operate on a non-shared object at the same time), but in the
> general case, I would not expect it to be able to assume that it won't be used
> across threads in the future without being wrong.

I feel a little uneasy about that aswell, but I haven't really digged 
very deep into the implementation yet. Here's an example of a string 
shared between two threads, but no "shared" type around:

module test;
import std.stdio;
import core.thread;

immutable(string) hello;

shared static this()
{
	hello = "Hello";
	hello ~= ", ";
}

void thread1()
{
	string h = hello;
	h ~= " World";
	writeln("1: ", cast(void*) hello.ptr, " ", cast(void*) h.ptr, " ", h);
}

void thread2()
{
	string h = hello;
	h ~= " D";
	writeln("2: ", cast(void*) hello.ptr, " ", cast(void*) h.ptr, " ", h);
}

void main()
{
	auto t1 = new Thread(&thread1);
	auto t2 = new Thread(&thread2);
	t1.start();
	t2.start();
	t1.join();
	t2.join();
}

Output is:
1: 1E83FF0 1E83FF0 Hello,  World
2: 1E83FF0 1E83F80 Hello,  D

Which shows that the first thread appended in place, and the second 
reallocated. This is correct, but if both array append operations are 
executed concurrently, are the problems not the same as with "shared" 
strings?