[dmd-concurrency] draft 8: the final countdown

[Andrei Alexandrescu]

Michel Fortin wrote:
> 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.

OK, great. I mean whew!

> 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.

I see; good idea. So everything not marked explicitly as shared, at any 
level, would be considered owned and can't escape. Beyond a point, the 
switch is turned and stuff becomes shared, and so can escape no problem.

I'll talk to Walter about what it takes to implement this.

This scheme only works for arrays and pointers, but they are frequent 
enough to warrant such a rule. Classes remain the way they are - they 
have to fend for themselves.

Thanks! This is a great idea.


Andrei