On 2010-01-08 03:50:26 -0500, Walter Bright <[email protected]> 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
[email protected]
http://michelf.com/
