Re: Threading in new C++ standard
Szabolcs Ferenczi a =E9crit :
On Apr 18, 12:49 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 16, 6:21 pm, Ke Jin <kjin...@gmail.com> wrote:
[...]
I cannot see the language features for concurrency but only the
library ones.
The biggest advancement that C++0x will add to C++ in the
are of threading (other than acknowledge that it exists of
course)
Whether C++0x acknowledges threading or not, that does not
affect threading. Do you seriously think that threading will
die out if C++ will not deal with it?
No, but C++ will gradually die out if it doesn't acknowledge
threading.
is the introduction of a (quite advanced, BTW) memory model,
which is a *pure* language feature.
Is that all? The argument went that other solutions are not
good because they are library based whereas the C++0x provides
solution at the language level. What are the language level
elements then?
A memory model "is a *pure* language feature?" Sure? By the
way: Do you know any programming languages which are designed
for concurrency at the language level rather than at the
library level? Do they have anything to do with any "memory
model"? (Hint: Try to thing something else than Java.)
Posix C. Posix defines more or less how memory accesses work in
the presence of threads.
And Ada, and Eiffel, and probable a number of others.
[...]
Everything else is pretty much just standardizing pretty the
status quo.
That's not quite true. The status quo is often that you don't
know what guarantees you have. The standard seeks to aleviate
this.
The status quo of what? Pthreads library? Boost library? ACE
library? or what?---since C++ has currently nothing to do
with concurrent programming.
The main issue isn't the library interface (although that is
important too). The main issue involves language rules: when
must a compiler ensure that a write is visible in other threads,
for example.
[...]
Consequently the compiler will not be able to check
whether the shared data is accessed properly inside
critical region or not.
The memory model prohibits any optimizations (very few
actually) that could break properly locked (or fenced) code.
I did not talk about optimisation but that a concurrent
language must provide some means to mark the shared resource
and then the compiler *must* check whether the shared resource
is really accessed within the critical region only. This
cannot be substituted by any memory model or optimisation.
You may not have talked about optimisation, but it is certainly
an important issue. As is visibility.
Anyway, a high level language is not about optimisations.
Optimisation is a technical issue for the compiler. However,
the compiler is not there, in the first place, to optimise but
to translate one notation to another.
A language must define which optimizations are legal, and which
ones aren't.
Once upon a time an eminent scholar said: "There are two views
of programming. In the old view it is regarded as the purpose
of our programs to instruct our machines; in the new one it
will be the purpose of our machines to execute our programs."
https://www.cs.utexas.edu/users/EWD/transcriptions/EWD05xx/EWD512.html
Certainly. But if the language doesn't define what a statement
means, you can't use it at either level. C++ currently doesn't
define what a statement means in a multithreaded envirionment.
Doing so is a language issue.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34