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
