Concurrency architecture for D2

[Michel Fortin]

On 2010-01-08 03:50:26 -0500, Walter Bright <newshound1 at digitalmars.com> said:

> 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.
> [...]
> 
> 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'm not sure what you're replying to in the above message. I was simply 
saying that to accomplish progress in something, the only necessary 
condition is to have an understanding among those who will actually 
implement that thing. Other opinions can be very useful, they can also 
be irrelevant, but you don't absolutely need a consensus among every 
participant in the discussion for something to advance.

You're making a case for making "shared" help programmers because most 
don't grasp all the implications of shared memory between processors. 
That's good but I don't really see how it relates.

By the way, I have seen my lot of multithreaded code in C++, sometime 
very well written, sometime just wrong, and sometime correct but 
obscure enough that takes help from the original author to understand. 
I've written code that probably enters in all these categories, and 
debugged my share of hard to track concurrency issues too. Were I was 
working previously, the most time-consuming bugs were always 
concurrency issues, generally race conditions happening every few 
hours/days or in certain rare conditions but not always, causing either 
deadlocks or other problematic behaviors. Fortunately, we also had 
failsafes to stop things in case the software would crash as it had 
safety implications.

Although I'm no longer working there and dealing much less with 
concurrency issues now, I'm still interested in the subject.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/