[D-runtime] Precise garbage collection

Jonathan M Davis jmdavisProg at gmx.com
Sat Jun 22 19:07:31 PDT 2013


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.

Well, it's likely to be common to construct stuff as thread-local and cast to 
shared for essentially the same reason that you have to do that with immutable 
(though it probably isn't required quite as much), so I would definitely expect 
code to be doing unshared -> shared.

And it's my understanding at this point that the pretty much the only way that 
shared is useable is that when you want to operate on it, you protect it with 
a synchronized block or mutex or whatnot and then cast away shared and do 
whatever operations you want to do on it, after which, it'll be shared again. 
If the runtime is doing stuff with thread-local caches or pools or anything 
which couldn't be used across threads once it's back to being shared again, 
then the whole lock and and cast away shared scheme won't work, in which case, 
shared becomes pretty much useless beyond the most basic of basic types and 
operations (like a shared bool used as a flag across threads).

There's also the issue of using std.concurrency to pass stuff across threads 
(which IIRC, doens't actually work with shared right now, but is supposed to), 
in which case, an object might not ever really be shared, but it does jump 
threads, so if something in the runtime expects something to live on the 
thread that it was created on just because it wasn't created as shared or is 
currently marked as shared, then it could be in for a rude surprise.

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.

- Jonathan M Davis


More information about the D-runtime mailing list