Re: Threads - When?
Le Chaud Lapin wrote:
Lourens Veen wrote:
The problem is not whether it will work or not, the problem is that
there is currently no way of writing a (guaranteed) portable C++
programme that uses threads. Currently, anything to do with threads
is undefined behaviour.
And IMO, that is the fault of the OS people and library writers, not
the language proper.
If the language says its undefined, no one else can make it
portably defined.
Let's take two simple cases from real life:
G++ (like everyone else, I think) uses objects with static
lifetime in its exception handling. Before 3.0, it used them in
such a way that if two threads raised an exception at the same
time, the exception object was corrupted. Please explain how
this is the fault of the OS people and library writers.
Also g++ pre-3.0: every constructor of std::string modified
(incremented, and often later decremented) a single global
counter object. You don't really expect users to use an
explicit lock everytime they construct a string, do you? Of
course, you might consider this a library issue, and not a
language issue, but std::string is defined in the C++ standard,
as part of the language.
The C++ language semantics are specified in terms of an
abstract "virtual machine" to make the language specification
independent of any OS. If we want to implement a threading library,
then we have to specify its semantics in terms of that virtual
machine, just like with the rest of the language. And to be able to
define a mutex and say "No more than one thread shall own a mutex at
the same time", the virtual machine needs to support multithreading.
I would agree with this point of view under one condition: absolutely
no changes to C++ would be made.
But adding such statements would be a change. In fact, analysis
has shown that the sequence point model doesn't adapt at all to
a multithreaded context. So a major part of the definition of
expression semantics, and what is or is not conforming, will
change.
Note that I am not requesting that no
changes to C++ be made, I am trying to prove a point, which is...
Threading is an OS issue, not a language issue.
Threading is an issue at all levels. The OS can provide the
best primitives in the world, but if your code misuses them,
it's all for naught. At the lowest level, threading is a
hardware issue---if hardware does speculative loads, and pushes
loads forward (as modern hardware does), and doesn't provide the
necessary fence or membar instructions to inhibite this behavior
on command, there's no way an OS can offer the necessary
primitives. But of course, the OS has to play its part; you
don't want to have to implement all of the primitives in each
application, and typically, you probably can't, because some
things will require privileged mode. After that, the compiler
has to ensure that these primitives are actually available to
you, and that it doesn't automatically do anything forbidden in
the generated code. Intel processors have very few registers,
and so often have to spill in complex expressions. If the
compiler spills to static memory, it doesn't matter what the
processor and the OS offers. And of course, having a *standard*
interface, defined in the standard library, certainly helps
portability.
None of which, of course, means that the programmer can ignore
the issues, and not pay attention to threads. All it means is
that when I write a program, I only have to analyse its thread
safety once, against the standard guarantees, rather than for
each platform, against the guarantees given by that platform.
[...]
I get the feeling that C++ programmers are, perhaps, expecting some new
keywords to be added to the language to make threading easier, or
whatever.
From where do you get this feeling? My impression is just the
opposite, that there is an enormous resistance to adding any new
keywords for threading; that no one wants any new keywords for
thread support.
--
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! ]