[dmd-concurrency] draft 7

[Steve Schveighoffer]

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> 
> (I assume you meant "BankAccount[string]".)
> 
> It all depends on the behavior of the types shared(BankAccount[string]), 
> shared(BankAccount), and shared(string[]).
> 
> I didn't quite mention what happens to member arrays inside synchronized 
> methods. I think I wouldn't have to, but ~= warrants it. Here's the deal: inside 
> a synchronized method, a member of type T[] is shared(T)[], except if you want 
> to take the address of the member, in which case it's shared(T[]). Yep, that's 
> tail const. I haven't thought a great deal about this, but arrays of shared(T) 
> may be appended to efficiently.

I thought the decision was made (in discussing the array append ideas I implemented) that shared array appending efficiency was not important.

I don't see how it can be...  You must always take a lock while you are expanding a shared array, which has proven to be the major slowdown in the current released runtime.  Not using a lock reintroduces memory stomping, which I think we all agree is worse than inefficient shared array appending.

In short, even a tail-shared array points to a shared capacity field.  Updating that capacity field must be surrounded by a lock.

> I have given zero thought to shared associative arrays, and this is a great time 
> to start talking about it. For my money I think we need to have a whole separate 
> type SharedMap(K, V).

I agree there.

-Steve