[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