Re: Threads - When?
Le Chaud Lapin wrote:
James Kanze wrote:
Le Chaud Lapin wrote:
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++.
There are things that I could argue about all day. This isn't one of
them. It is patently obvious (to me) the nature of FSM's, atomic
operations, etc. I fail to see where the mystery lies.
That's because you don't understand threading. It's not a
mystery, but it's not trivial, either.
What more needs to be known? What is the committee looking
for?
To start with, a definition of the language which isn't based on
a single threaded model. Sequence points, for example, don't
mean anything in a multithreaded environment.
And for the record, I never said that threading was not
to be used because it can be abused. I use multi-threading
each day, every day, and have been for about 7 years.
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.
Great. multi-threading is good. I agree.
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.
Then what is there to discuss? What is expected to be found? What is
the problem that is being addressed?
For starters, define what it means in the context of C++ for a
multi-threaded program to run.
Jeffrey
I think we agree that threading is hard, and threading issues
(who is responsible for what, etc.) must be addressed at the
design level.
Well, in my case, it is not hard any more. I want to make it clear
that I *never* expected any magic from C++ to help me in
multi-threading.
Nobody is expecting magic. On the other hand, you can't very
well have undefined behavior the second you invoke
pthread_create (which is the current status, at least as far as
the standard is concerned).
The standard defines C++ in terms of an execution model, and
that execution model is single threaded.
I knew that any problems that I would have with
threading would be to
1. my own ignorance of the primitives available
2. deficiency in the primitive set
3. carelessness in the application of existing primitives.
Personally, I have fixed #1, at least enough that I have found closure
for big system design. I use most of the Windows synchronization
primitives except for atomic inter-locked exchange and friends and
fibers, which are not really threads. I also discovered, in my own
view, that #2 does not exist. The Windows team (old VMS guard) did a
great job here.
Actually, it's known and recognized that one of the most
important primitives, conditions, isn't present in Windows (or
rather wasn't---it's recently been added).
But you keep returning to "primitives". There's a lot more to
threading than that.
--
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! ]