Re: Threading in new C++ standard
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gmail.com> wrote:
On 19 avr, 20:03, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
However, if the language is missing any language level means
to define a critical region, that is a problem.
Why?
Well, because visibility becomes a problem only if the concept
of Critical Region is missing from the language level. If the
Critical Region is part of the language, there is no issue
like visibility.
You've got things backwards, I think. You're imposing a
specific solution. A language definition of a critical region
can define visibility, of course, but that's not the only
solution. And it's far from the best on.e
Visibility and memory model are very low level concerns
created by the library approach itself.
Note that this discussion thread has just started with the
claim that a library is not appropriate (some referred to the
Boehm article) but C ++0x handles concurrency at the language
level. E.g. ACE has been rejected with this claim.
No. Boehm claims that a library solution alone is not
sufficient. He never claims that the complete solution will not
contain any library elements. The programmer's API is in the
library. And since ACE just differs to the underlying platform
for this, it doesn't reject anything.
On the contrary, what we can see is that C++0x provides a
purely library-based approach for the threading, however, on
the other hand, C ++0x pays a great effort to (re)solve
problems created by the library approach.
You're not making sense. C++0x doesn't (or won't) provide a
purely library-based approach. Threading issues will be
addressed in the language. C++0x makes the distinction between
library issues (the API) and language issues (the memory model
and visibility).
Any decent concurrent programming language must provide some
language means to:
(1) mark the shared resources
(2) mark the associated Critical Regions
This way the compiler can and must check whether the shared
resource is accessed inside Critical Regions only.
=46rom what I understand, that's more or less the way Ada works.
The result is that everyone ends up creating larger structures
using this base, and running into the same problems.
In an object-oriented language the two issues (i.e. the shared
resource and the associated Critical Region) are naturally
combined in the concept of the shared class (see also
Monitor).
The checking function of the compiler can prevent a good deal
of concurrent programming errors
Funny. Concurrent programs in Ada have exactly the same
problems as those in C++.
and that is one of the main differences between library level
and language level. This essential difference is not discussed
in the Boehm paper which is a golden reference here somehow.
If you claim that you are going to tackle multi-threading at
language level in C++0x, it is unavoidable to incorporate
Critical Regions and Conditional Critical Regions. Well, you
should do so if the language level is the concern. Otherwise
you might play at low level such as libraries, visibility and
memory models but you should be aware of it too and not
claiming the language level.
I don't think you really understand what concurrency is all
about. Boehm's point, which has been accepted by the committee,
is that you have to address certain threading issues at the
language level. There was never a proposal for introducing the
threading API at the language level, however; that just seems
contrary to the basic principles of C++, and in practice, is
very limiting and adds nothing.
After all, it seems that in C++0x you were trying to collect
the elements of the state of the art library-based approaches
to multi- threading and, consequently, you had to extend C++
at the language level to deal with the problems generated by
the library-based approach. However, threading itself remains
at the library-level. I think we can summarise it that way,
can't we.
No. The language addresses threading, as it must.
--
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