Re: Threads - When?
Le Chaud Lapin wrote:
Dilip wrote:
Le Chaud Lapin wrote:
This is getting wildly OT so I will confine myself to correcting a
small misconception. Spinning need not cause any kind of "intolerable"
slowless as you put it. For an example how a spin-lock can be
implemented efficiently under windows, take a look at this:
http://msdn.microsoft.com/msdnmag/issues/05/10/ConcurrentAffairs/#S3
IMO, this is precisely on topic. There seems to be a lot of C++
programmers who think that they will be able to wield some special
magic to violate what I believe are fundamental principles in OS
design.
You keep claiming this, but you've presented no evidence for it.
And of course, the fact that bad programmers can abuse a feature
has never stopped it from being adopted into C++.
For what it's worth, I don't know of anyone on the committee who
isn't aware of the additional complexities that threading
implies. On the other hand, there are many cases where it is
the appropriate solution, and some where it is the only
solution. Ignoring it effectively either bans C++ from such
applications, or forces programmers to depend on implementation
definitions of undefined behavior.
I am glad we are discussing this, because, I intend to show
that that there is no magic, that there is nothing that will be done in
code to make us able to code-and-forget.
But everyone already knows that. There's no silver bullet.
First, spin-locks, from a C++ programmers point of view, cannot be
implemented efficiently.
Who cares? As far as I know, there's no proposal to add
spin-locks to the language.
Jeffrey
Richter writes:
"No programmer in his right mind wants to think about thread
synchronization as he is coding his app. This is because thread
synchronization has little to do with making the program do what its
true intention is."
At which point, I stopped reading, because the author obviously
doesn't know much about threading and thread safety.
I think we agree that threading is hard, and threading issues
(who is responsible for what, etc.) must be addressed at the
design level.
These two sentences prey upon what I believe is a false notion that
programmers are going to be able to avoid multi-threading issues
altogether and "just code". This is false. It is possible to build a
system were every single access to state is protected by a mutex, and
that would work,
Probably not. The granularity is too small.
There is no silver bullet. Threading must be part of the high
level design.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]