Re: Threads - When?
Le Chaud Lapin wrote:
James Kanze wrote:
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.
The person who wrote that part of the G++ library probably expected it
to be used in a single-thread application.
Exactly. (And it's not part of the library, at least not
formally. Exceptions are part of the language.)
That's what I've been saying all along. You need some
guarantees from the compiler.
If it had been intended to
be used in a multi-threaded application, the library writer should have
written it for multi-threaded applications. If he did not write a
multi-threaded version, then that is the fault of the library writer.
There's no "fault". The standard doesn't recognize multiple
threads. The compiler implemented the standard.
If I write a program that contains 10 threads, and they all invoke
operator new() simultaneously, and cause the heap to become corrupted,
that will be either my fault, or the library writer's fault.
In the absence of a contract, it's your fault. And the only
contracts today are from the compiler vendors, and they vary
from one compiler to the next.
[...]
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.
Statements or library functions?
Statements, but does it matter? The only thing that matters, in
the end, is that it is code that you didn't write directly, but
that is provided for you in one way or the other by the compiler
(or a third party vendor---the issues are the same, but third
party software doesn't normally come under the scope of the
language specification).
Note that is entirely conceivable
that, at the end of the day, the code that uses "standard" C++
multi-threading support by way of libraries does not have much visual
distinction from that which supports by way of added keywords. The
thesis of what I am saying, that it is my opinion, based on my own
experience, that changes to the language are not necessary, any more
than it is necessary to change the language to grab random numbers from
the architecture, for example.
Well, you certainly need guarantees from somewhere. We've
pointed out no end of reasons here. And from where else, if not
from the language standard. Leaving it to the implementors
means every compiler gives a different set of guarantees, and
even the simplest portable code is chancy.
[...]
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.
???? Spill to static memory?
Compilers have been known to do it.
What about the stack?
On a modern IA-32 processor, that's the obvious place. On other
processors, it varies; it's the obvious place on most modern
architectures, but accessing stack based memory can be very
expensive on some older architectures.
My point is simply that you need a guarantee that the generated
code is thread-safe if you are going to use the compiler for a
multithreaded program. You have been denying that the compiler
has anything to do with it, but it does. At the lowest level,
it is the compiler which writes the machine code, not you, and
it is the code at the machine code level which ultimately
determines whether your function is thread-safe or not.
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 do sympathize with the "mood" that you seek. I am 100% in agreement
with having the programmer feel good while using the primitives for
multi-threading Again, I think that "feel good" can be achieved
entirely using libraries without perturbations to the language itself.
It has nothing to do with "feel good". In order to write thread
safe code, you need certain guarantees from the compiler. I and
others here continue to show examples as to why, and you
continue to ignore them. Unless you have a guarantee that the
machine code generated by the compiler is thread safe, you
cannot safely use the compiler for multithreaded applications.
And unless this guarantee is present in some standard document,
you cannot use it portably: different vendors give different
guarantees. Today.
[...]
The last complaint is particularly important. It gives the impression
that, if the problem is being complained about, then those who are
doing the complaining do not know what is the solution.
There are two aspects to the solution. The experts all know
that we need to add support to the language for threading. If
not, we remain in the current situation, where portable
multi-threaded code is not possible (and I'm not talking only
about the names given to the primitives). That's the
"solution". There is a lack of consensus with regards to
exactly what should be guaranteed, at least with regards to
certain details. (I think that there is consensus on the
fundamental points, e.g. that concurrent access to an object is
undefined behavior if any thread attempts to modify the object,
but legal and defined otherwise, and that with a few exceptions
(e.g. bit fields), accessing different objects may take place
concurrently, regardless of the type of access. And that the
only accesses you have to worry about are those in your
code---if a compilers spills to static memory, it has to
generate whatever synchronization is necessary. I don't
remember hearing the issue discussed, but I hope that there is
also consensus that you can throw concurrently from several
threads. I don't think that there's any consensus yet with
regards to the construction of local static variables,
however---at present, g++ allows it, Sun CC (and I think VC++)
doesn't. And there is definitly discussion concerning the
meaning of volatile, and the implications of causality.)
Otherwise,
they would not be complaining.
People are complaining today because it is impossible in C++
today to write portable, correct code for a multithreaded
environment.
And if they do not know the solution,
they are not yet aware that these problems can be easily fixed using
existing primitives (libraries) that are entirely orthogonal to the
language itself (as is my opinion and that of others).
And that is simply false. You keep repeating yourself, and
ignoring the many examples others have posted indicating why it
isn't sufficient.
And if they
complain in the context of c++.moderated, there is the impression that,
not only are libraries not enough, something more must be done with
C++.
Which is a proven fact.
But if the libraries are not enough, the only thing left to be
done with C++ is to change the language itself.
Correct.
Note that changing the language does NOT necessarily mean
introducing new keywords. It does mean, for example, redefining
the concept of sequence points so that it has some meaning in a
multi-threaded context. And ensuring that things like spilling
to static memory, or using unsynchronized modifications to
static memory in exception handling, result in some way in an
non-conforming implementation. And either explicitly requiring
the user to externally synchronize when calling a function with
a local static variable with non-trivial initialization, or
explicitly saying that such a function can be called
concurrently. And adding text which forbids some implicit
parallelization: off hand, for example, I think that the
standard will have to guarantee that the initialization of
static objects (at namespace scope) does not take place
concurrently. (To be frank, I'm not even sure we have that
guarantee today.) And no doubt a lot of other things I haven't
mentionned.
--
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! ]