Concurrency architecture for D2

[Nick B]

Andrei Alexandrescu wrote:

> 
>> In Bartosz reply on 14 Oct 2009, [subject: Re: Revamped concurrency 
>> API], detailing his detachment from the D community, he gave this 
>> opinion: " I'm a bit of a perfectionist and it's hard for me to 
>> subscribe to the "good enough" philosophy (as long as it's better that 
>> C++, it's fine for D)".  If the three of you, can't agree on approach 
>> and architecture then I suspect, there is little to be said further.
> 
> There's more than one side to each story. My choice of words describing
> the situation would be quite different, but please allow me to keep that
> to myself. Let me just emphasize that the "good enough" philosophy and 
> using C++ as the sole yardstick does not characterize D's development.
>
Agree,  everyone does have their own point of view.
[snip]
> 
>> 2.   Can you explain further this comment (see above ref) by Bartosz:
>> " The semantics of "shared". I can live with postponing the 
>> implementation of the race-free type system, but not with the compiler 
>> inserting barriers around all shared reads and writes, even inside 
>> synchronized sections. "
> 
> A shared object allows synchronized calls. However, shared is deep and
> the effect of synchronized is shallow, so there is a conflict. What
> synchronized effects is a sort of "tail-shared". Walter's and my
> suggestion was to have synchronized _not_ change the type of the object.
> That way, the type of each field of the object remains shared-qualified
> inside a synchronized method, which is correct but overly conservative.
> In theory the compiler emits barriers whenever reading and writing
> shared fields. However, inside a synchronized method, the compiler can
> elide barriers because it understands shared is really tail-shared. Yet
> there will still be more barriers than strictly necessary because e.g.
> you could pass the address of a field to another function, which doesn't
> realize the field is lock-protected. Walter and I deemed the situation
> rare enough to not complicate the language with the likes of "tail-shared".
> 

Thank you for this clarification.


>> 3. Finally, is this a requirement to be finished for your book, or is 
>> this a separate issue ?
> 
> If TDPL comes without addressing concurrency, or if if comes with
> something, ahem, not-so-good a la Python, we may as well gather our toys
> and go home.
> 

I am sure you and Walter will deliver something good and robust.

Nick B