[dmd-concurrency] draft 8: the final countdown

[Michel Fortin]

Le 2010-02-10 à 16:54, Andrei Alexandrescu a écrit :

>> Are you saying you cannot access public members of a thread-unware
>> object? This would lead to a race in this situation.
> 
> You can, but they're qualified with shared, just the same way the synchronized method sees them. There is no race. I'm sure there is a misunderstanding somewhere.

I agree there is no race as long as you don't put a cast in there. If you go back a few emails, you'll note that I was talking about the context where you want to have something owned beyond an indirection. In this situation the compiler is more than unhelpful since not only you need a cast (but I digest), it also allows you to escape your "owned beyond an indirection" data without a cast.

I'm saying that this will be a common enough case that it should be better. If it wasn't a common enough case you wouldn't have that "cast away shared" chapter. So in that common enough case that require a cast you'll not only need a cast, but you'll also need to be extra cautious about what escapes even in functions that do not have a cast.

So I was simply suggesting that the compiler helps by knowing up to what level of indirection the data is "owned". For instance, by my suggestion, this:

	synchronized class A {
		int[] x;
		shared(int)[] y;
	}

has member x is owned entirely (including the referenced data) by the object while for member y only the head (or tail? I'm always mixing those terms) is owned. This means you can't take the address of x's content (just like you can't take the address of x or y). Well, you can, but you need a cast.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/