Concurrency architecture for D2

[Andrei Alexandrescu]

Nick B wrote:
> Andrei Alexandrescu wrote:
>>> Nick B wrote:
> 
>>> Andrei
>>>
>>> Will you be inviting Bartosz to participate, or have you already has 
>>> discussions with him ? He has written a number of  blogs around this 
>>> issue.
>>>
>>> Nick B
>>
>> I'm not sure about Bartosz' and Walter's thoughts. I personally think 
>> that past experience suggests that collaboration would be difficult. 
>> No less than three attempts to work together on threads ranging from 
>> design to implementation have failed, in spite of everybody's best 
>> intentions.
>>
>> Andrei
> 
> Andrei
> 
> Very interesting to see that you and Walter tried three times !!

Bartosz too. We all tried, and if we failed I can say for sure it wasn't
for the lack of good intentions.

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

> All I can ask is:
> 
> 1.  if you could re-read his blog posts on this subject.

I am familiar with Bartosz's posts and with the work he is building on.

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

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


Andrei