On Sat, Oct 19, 2013 at 7:36 AM, Bennie Kloosteman <[email protected]>wrote:
> You could just go like RC-Immix that references cant be passed to other > threads ? > Where do they say that? I'm pretty convinced that it can't be enforced without a read barrier of some sort, and they make no mention of having one. > The key here is how long objects are in a Nursery. > Nope. You can construct cross-nursery references even if the nursery only holds a single object. It may take longer for the race to emerge, but it's possible. The problem here, really, is to avoid the need for any sort of all-mutators halt. Even if that halt is just to clear the nurseries together, the need to synchronize the halt is not happy-making. I toyed with the possibility that objects might only be allowed to pass between threads through some form of cross-thread stream object, which would give us a place to stand to do whatever we need. Unfortunately I don't think that works in practice, because objects live in shared memory. I also considered the possibility that acquiring a lock on an object in somebody else's nursery would cause the acquiring thread to block until the object has been moved to the tenured heap. That isn't pretty, but it preserves safety and nursery-flush independence. If threaded objects can be explicitly allocated in a non-local nursery, it might even be tolerable, but I kinda think not. If you have region analysis in the compiler, you can often create these objects in tenured space to begin with, and then there's no problem. But we can't rely on region analysis for this, because some source languages don't provide that. So I'm at a bit of a loss on this one. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
