Leandro Lucarella <llucax@gmail.com> writes:

> Then you will looove Gmane, because it is exactly that a NNTP gateway for almost any ML

As an example, this mailing list is available there as group

  gmane.comp.lang.d.general

However, the mailing list doesn't seem to accept posts through Gmane, despite the reported status of "posting allowed" here:

  http://dir.gmane.org/gmane.comp.lang.d.general

-- 
Steven E. Harris

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

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.

All I can ask is:

1.  if you could re-read his blog posts on this subject.

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

3. Finally, is this a requirement to be finished for your book, or is this a separate issue ?

cheers
Nick B

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

Andrei Alexandrescu Wrote:

> Nick B wrote:

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

The way things are going, I can't see things turning out any other way. Everything involving concurrency/shared seems to get pushed off. This thread is a recent example: asking for participants and then having no meaningful follow-up. When I was part of the sausage-making emails you and Walter were nearly silent, even in response to messages such as "can we at least agree to X?"

Jason House wrote:
> Andrei Alexandrescu Wrote:
> 
>> Nick B wrote:
> 
>>> 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.
> 
> The way things are going, I can't see things turning out any other
> way. Everything involving concurrency/shared seems to get pushed off.

We already have a compelling message-passing model designed and to a large extent implemented by Sean Kelly, so you can discount that risk.

> This thread is a recent example: asking for participants and then
> having no meaningful follow-up. When I was part of the sausage-making
> emails you and Walter were nearly silent, even in response to
> messages such as "can we at least agree to X?"

There are a few clerical issue to take care of, and I'm not sure what Walter's preferred method of communication is. I will make you part of whatever transport we'll use.

I am sure that some questions weren't answered simply because there was no clear answer. Besides, email communication is imperfect.


Andrei

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

On Sun, 27 Dec 2009 14:32:52 -0600, Andrei Alexandrescu wrote:

> I think we are now in the position of defining a solid set of concurrency primitives for D. This follows many months of mulling over models and options.
> 
> It would be great to open the participation to the design as broadly as possible, but I think it's realistic to say we won't be able to get things done on the newsgroup. When we discuss a topic around here, there's plenty of good ideas but also the inevitable bikeshed discussions, explanations being asked, explanations being given, and other sources of noise. We simply don't have the time to deal with all that - the time is short and we only have one shot at this.
> 
> That's why I'm thinking of creating a mailing list or maybe another group for this. Any ideas on what would be the best approach? I also want to gauge interest from threading experts who'd like to participate. Please advise: (a) whether you would like to participate to the design; (b) keep discussions on the general group; (c) create a separate newsgroup; (d) create a mailing list. The latter would have open enrollment.
> 
> 
> Andrei

I would love to be involved too.

Graham St Jack wrote:
> On Sun, 27 Dec 2009 14:32:52 -0600, Andrei Alexandrescu wrote:
> 
>> I think we are now in the position of defining a solid set of
>> concurrency primitives for D. This follows many months of mulling over
>> models and options.
>>
>> It would be great to open the participation to the design as broadly as
>> possible, but I think it's realistic to say we won't be able to get
>> things done on the newsgroup. When we discuss a topic around here,
>> there's plenty of good ideas but also the inevitable bikeshed
>> discussions, explanations being asked, explanations being given, and
>> other sources of noise. We simply don't have the time to deal with all
>> that - the time is short and we only have one shot at this.
>>
>> That's why I'm thinking of creating a mailing list or maybe another
>> group for this. Any ideas on what would be the best approach? I also
>> want to gauge interest from threading experts who'd like to participate.
>> Please advise: (a) whether you would like to participate to the design;
>> (b) keep discussions on the general group; (c) create a separate
>> newsgroup; (d) create a mailing list. The latter would have open
>> enrollment.
>>
>>
>> Andrei
> 
> I would love to be involved too.

Subscribe to dmd-concurrency from http://lists.puremagic.com/.

Andrei

Michel Fortin wrote:
> Also keep in mind that we don't really need a shared vision among everyone. What's needed is someone who takes the decisions. Discussion is only needed to help that person take the right decisions. Although consensus among all members certainly boosts the decider self-confidence, it is not required, and not necessarily desirable either. A consensus among only a few key people is all that is needed, and this has little to do with who is allowed to raise issues and propose solutions.

The real problem with a concurrency model is that very few programmers understand the issues. The failed Java concurrency model is an example of this shortage. For another, about 5 years ago I attended a panel of 30 of the top C++ experts in the world to discuss a concurrency model for C++0x.

It didn't take long for it to become obvious that exactly two people understood the issues - Hans Boehm and Herb Sutter. The rest of us sat there slack-jawed and drooling, asking endless inane questions. I wish I had the patience Hans and Herb showed in dealing with this.

Since then I have tried to master this topic, but I don't have much experience writing complex multithreaded code. So what we need are people who are experienced with MT code who can evaluate the design to see if we missed the boat or not. I'd rather not shoot at the moon yet wind up orbiting some asteroid.

Walter Bright Wrote:

> Since then I have tried to master this topic, but I don't have much experience writing complex multithreaded code. So what we need are people who are experienced with MT code who can evaluate the design to see if we missed the boat or not. I'd rather not shoot at the moon yet wind up orbiting some asteroid.

I can't comment on the future threading model, but I have been trying to use the current one by converting an existing multithreaded app. I've gotten a lot further than my last update on this list. Bugzilla 3660 is quite severe. My current understanding of the issue is that matching of function templates to attempted function calls isn't aware of the distinction between shared and non-shared functions.