473,898 Members | 4,144 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Threading in new C++ standard

Rather than create a new way of doing things:
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
why not just pick up ACE into the existing standard:
http://www.cse.wustl.edu/~schmidt/ACE.html
the same way that the STL (and subsequently BOOST) have been subsumed?
Since it already runs on zillions of platforms, they have obviously worked
most of the kinks out of the generalized threading and processes idea (along
with many other useful abstractions).

Even more interesting than generalized threading would be generalized
software transactions. The Intel compiler has an experimental version that
does this:
http://softwarecommunity.intel.com/a...s/eng/1460.htm

As we scale to larger and larger numbers of CPUs, the software transaction
model is the one that gains traction. This document is very illuminating in
that regard:
http://internap.dl.sourceforge.net/s..._submitted.pdf


** Posted from http://www.teranews.com **
Jun 27 '08
126 6788
On Apr 17, 11:31 pm, "Chris Thomasson" <cris...@comcas t.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren ...@gmail.comwr ote in message
news:24******** *************** ***********@d1g 2000hsg.googleg roups.com...
On Apr 16, 12:28 am, "Dann Corbit" <dcor...@connx. comwrote:
Rather than create a new way of doing
things:http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
...
I like that some higher level construction is also there at last (at
condition_varia ble):
[...]
Indeed. That's a major plus for me. The really cool thing, for
me at least, is that the next C++ will allow me to create a
100% standard implementation of my AppCore library
<http://appcore.home.co mcast.netwhich currently uses POSIX
Threads and X86 assembly. The fact that C++ has condition
variables, mutexs, atomic operations and fine-grain memory
barriers means a lot to me. Finally, there will be such a
thing as 100% portable non-blocking algorithms. I think that's
so neat.
That was, I believe, a do or die requirement from some of the
participants.

I haven't mentionned it much here because it's not really
relevent to the work I do, and I'm not too familiar with it.
But it is definitly one reason why just adopting an existing
library isn't sufficient. Threading is used for different
purposes, at different levels, and someone who's interested in
parallelizing array operations on a multi-core system will have
different requirements than someone who just needs a worker
thread in a GUI.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #21
On Apr 18, 12:49 am, Szabolcs Ferenczi <szabolcs.feren ...@gmail.com>
wrote:
On Apr 16, 6:21 pm, Ke Jin <kjin...@gmail. comwrote:
First, ACE thread is a library based solution. There are many
discussions on why C++0x thread choose a new language based approach
instead
(See <http://www.artima.com/forums/flat.jsp?forum= 226&thread=1809 36>
and Boehm's article of "threads cannot be
implemented as a library").
Is not "Multi-threading Library for Standard C++" just another
library?

Did you read Bohem's article?
Sure I did. What else?
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?
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.)
Also it introduces atomic operations which must be implemented at
the language level.
They are just part of yet another *library* in C++0x. So how do you
connect them to the language level?
Everything else is pretty much just standardizing pretty the status
quo.
The status quo of what? Pthreads library? Boost library? ACE library?
or what?---since C++ has currently nothing to do with concurrent
programming.
For instance, you can instantiate a thread from a
library class. There is no language element for defining a thread, is
there?

So what?
So, it is a *library* issue and not any language issue. Just that.
There is no keyword in C++0x to mark the shared data.

No need for that if you use locks. For small atomic POD objects there
is the atomic<template class which uses the appropriate magic to
make access atomic without locks.
If you use locks, you are at the library level. If you claim that in
contrast to other solutions which are library level solutions C++0x
provides language level ones, what are they?
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.

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.

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/...xx/EWD512.html

Clearly, times has changed: The current trend is that we must write
programs for the compiler to optimise it. So we might adapt the
saying: "There are two views of programming. In the old view it is
regarded as the purpose of our programs to BE EASILY OPTIMISED BY
COMPILERS; in the new one it will be the purpose of our COMPILERS to
COMPILE our programs." I rather support the latter view.
The low level library means such as mutex and condition variable are
there but there is no higher level language means to define a critical
region

scoped_lock? Why do you need a language level mean when a library
approach
works just fine and is more in line with the 'C++ Way'
First of all some people here claimed that C++0x provides language
level solutions to multi-threading as opposed to the library
solutions. Well, scoped lock belongs to the library level. Is it
really the 'C++ Way'?

On the other hand, in concurrent programming it is even more important
to stay closer to the problem set rather than to the hardware or
library level. There is one important issue most of the people who
thinks there was no life before the pthread library forget about: The
compiler is not there to optimise your code. The compiler must help
you to write correct code and bridge the gap between the high level
human oriented notation and the low level machine language. In case of
concurrent programs it is even more important than it was in case of
sequential programs that the compiler should catch concurrent
programming errors at compile time, if possible. The compiler can only
do that if you use redundant high level language to express what you
want to achieve. If the compiler does the job, however, the translated
code will not be redundant.

If you use library calls, you are at the low level, the compiler
cannot help you much, as is explained in the referenced paper: Boehm
"Threads Cannot be Implemented as a Library" By the way, did you read
it at least?
or conditional critical region or monitor (see the `shared
class' as it was originally proposed). I mean at the language level
you have nothing new compared to the library level. At least I cannot
see anything like that in the attached "Multi-threading Library for
Standard C++ (Revision 1)"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2497.html#th.. .

Higher level abstractions can (and will) be built on top of the low
level infrastructure as pure library extensions.
If you do that in the user code, the compiler support is lost. On the
other hand, you can do that in any library, you do not need C++0x at
all for that. However, this way you will never have high level
abstractions at the language level, since you are going to stay at
library level "as pure library extensions."

Best Regards,
Szabolcs
Jun 27 '08 #22
Szabolcs Ferenczi a écrit :
On Apr 18, 12:49 am, Szabolcs Ferenczi <szabolcs.feren ...@gmail.com>
wrote:
On Apr 16, 6:21 pm, Ke Jin <kjin...@gmail. comwrote:
[...]
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/...xx/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:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #23
On Apr 19, 9:25*am, James Kanze <james.ka...@gm ail.comwrote:
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.
It is a good example. The visibility is quite straightforward issue in
any decent concurrent programming language: At the end of the critical
region a write that happened inside the critical region is visible to
the other threads.

However, if the language is missing any language level means to define
a critical region, that is a problem. It is typically the case when a
language offers library level means for concurrency.

In C++ it could have been solved with a single keyword: `shared'. A
shared class is basically a monitor (note that originally the monitor
was introduced as a shared class). Here is an example:

shared class A {
int x;
public:
int s(const int n) {const int t = x; x = n; return t;}
};

The `x' is a critical resource which can be accessed inside a critical
region only. The compiler can implement the critical region with the
most appropriate low level means on a given platform. The language
level, however, is platform independent. Here the visibility is clear
and simple.

Best Regards,
Szabolcs
Jun 27 '08 #24
"Szabolcs Ferenczi" <sz************ ***@gmail.comwr ote in message
news:5b******** *************** ***********@c58 g2000hsc.google groups.com...
On Apr 19, 9:25 am, James Kanze <james.ka...@gm ail.comwrote:
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.
It is a good example. The visibility is quite straightforward issue in
any decent concurrent programming language: At the end of the critical
region a write that happened inside the critical region is visible to
the other threads.
However, if the language is missing any language level means to define
a critical region, that is a problem. It is typically the case when a
language offers library level means for concurrency.
POSIX Threads puts restrictions on C compilers such that threading is
defined without any need for new keywords; its not a problem.

In C++ it could have been solved with a single keyword: `shared'. A
shared class is basically a monitor (note that originally the monitor
was introduced as a shared class). Here is an example:
shared class A {
int x;
public:
int s(const int n) {const int t = x; x = n; return t;}
};
[...]

That's at a too high of level for C++. What if you wanted to atomically
modify x without using any locks? What if you wanted fine-grain control over
memory barriers involved? What if you wanted to be able to place the
barriers exactly where you want them? How does a shared keyword help? What
if I wanted to use plain loads and stores with membars instead of
interlocked rmw instructions?

Jun 27 '08 #25
On 19 avr, 20:03, Szabolcs Ferenczi <szabolcs.feren ...@gmail.com>
wrote:
On Apr 19, 9:25 am, James Kanze <james.ka...@gm ail.comwrote:
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.
It is a good example. The visibility is quite straightforward
issue in any decent concurrent programming language: At the
end of the critical region a write that happened inside the
critical region is visible to the other threads.
Which is a language issue.
However, if the language is missing any language level means
to define a critical region, that is a problem.
Why?
It is typically the case when a language offers library level
means for concurrency.
Posix does it for C, without any real problems. It means that
language issues and the library are somewhat mixed, but there's
nothing new there.
In C++ it could have been solved with a single keyword:
`shared'. A shared class is basically a monitor (note that
originally the monitor was introduced as a shared class).
Here is an example:
shared class A {
int x;
public:
int s(const int n) {const int t = x; x = n; return t;}
};
The `x' is a critical resource which can be accessed inside a
critical region only.
Which covers about 10% of the reasonable uses. I rather prefer
the way it is being handled, where I have more options when I'm
building my higher level abstractions.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #26
On Apr 20, 10:33*am, James Kanze <james.ka...@gm ail.comwrote:
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.

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.

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.

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. 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 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.

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.

Best Regards,
Szabolcs

P.S.: Once you know the details of the new proposal so well, would you
be so kind and publish some canonical concurrency problems solved in C+
+0x here, just to see how the proposal works out in some real code.
http://groups.google.com/group/comp....07b37a3b0323f3
Jun 27 '08 #27
On Apr 20, 1:42 pm, Szabolcs Ferenczi <szabolcs.feren ...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gm ail.comwrote:
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.
If you use locks, std::scoped_loc k (or whatever it is called today),
will mark your critical section just fine: even if it is defined in
the standard library it doesn't means that compiler can't or doesn't
have to apply appropriate magic to it.

If you use low levels atomic operations, then a critical section is
of very little use. The standard committee decided, IMVHO correctly,
that, as a system level language, C++ has to provide the most fine
grained approach to concurrency as possible (from relaxed atomics
to locks and condition variables).
Visibility and memory model are very low level concerns created by the
library approach itself.
No. Java has an high level approach to concurrency (monitors
and synchronized methods), but still defines a memory model.
In fact the C++ memory model has been heavily inspired by Java.
>
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.
A library *alone* is not sufficient. The compiler must be aware of
threading for the program to work correctly. Even posix threads,
apparently a pure library solution put some requirements on the
compiler (see the recent try_lock discussion on the gcc mailing list).
E.g. ACE has been
rejected with this claim.

On the contrary, what we can see is that C++0x provides a purely
library-based approach for the threading,
How the memory model is a purely library based approach? How can you
implement atomic operations with a pure library extensions?
How can you be sure that a try_lock will work without the compiler
being is explicitly prohibited to perform speculative stores?
How can you be sure that the compiler doesn't move operations in or
out
of a critical section? C++0x is a language based approach. The
interface,
as most of C++0x appears as a library feature (and the idea is that it
could be implemented as such, as with little help from the compiler
as possible, but some help is needed).

BTW, the standard allows std::vector (or anything else in the standard
library) to be implemented as language construct!
however, on the other hand, C
++0x pays a great effort to (re)solve problems created by the library
approach.
You have to prove this claim.
Any decent concurrent programming language must provide some language
means to:

(1) mark the shared resources
(2) mark the associated Critical Regions
This is of course your opinion. Certainly C++ allows the second via
scoped_lock. You can do the first easily via encapsulation.
This way the compiler can and must check whether the shared resource
is accessed inside Critical Regions only.
But won't prevent you from deadlocking nor starving other threads or
many more common multithread problems. Letting your self blow up your
foot has always been C++ philosophy :)
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).
C++ is not (only) an OO language. And anyways, implementing a monitor
with std::condition_ variable and std::mutex (or whatever their names
are), is pretty trivial.

But with the tools C++0x will provide you can also build other
abstractions; for example in the multithread programming community
there
is some certain interest in the Join Calculus, and it would be
interesting to see it implemented in C++.
>
The checking function of the compiler can prevent a good deal of
concurrent programming errors 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.
I think this is considered a quality of implementation issue.
Producing
good thread debugging tools is very hard, and the standard does not
mandate a c++ compiler to implement them. You can get them from
a third party, but it is going to cost $$!
>
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.
You should be aware that just because these facilities have a library
interface in C++, it doesn't means that they aren't part of the
language.
The line between the library and the language is much tinnier in C++
than
in other languages.
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.
The previous two major C++ thread interfaces (Win32 threads and
POSIX threads) certainly are not a pure library based approach,
but their requirements on a compiler were a bit fuzzy or not
existent at all. C++0x took care to formalize that. There doesn't
seem to be any need to be beyond that. A pure language based solution
would mean: no lock-free data structures and algorithms, no (easy)
way to replace the compiler provided thread API, any user extension
would feel second class etc.
However, threading itself remains at the library-level. I
think we can summarise it that way, can't we.
Far from that.
>
P.S.: Once you know the details of the new proposal so well, would you
be so kind and publish some canonical concurrency problems solved in C+
+0x here, just to see how the proposal works out in some real code.http://groups.google.com/group/comp....07b37a3b0323f3
I do not know the details, I'm not a threading exert nor I have the
time
to write 'real code' for you.

--
gpd
Jun 27 '08 #28
On Apr 20, 3:45*pm, gpderetta <gpdere...@gmai l.comwrote:
On Apr 20, 1:42 pm, Szabolcs Ferenczi <szabolcs.feren ...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gm ail.comwrote:
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.

If you use locks, std::scoped_loc k (or whatever it is called today),
will mark your critical section just fine: even if it is defined in
the standard library it doesn't means that compiler can't or doesn't
have to apply appropriate magic to it.

If you use low levels atomic operations, then a critical section is
of very little use. The standard committee decided, IMVHO correctly,
that, as a system level language, C++ has to provide the most fine
grained approach to concurrency as possible (from relaxed atomics
to locks and condition variables).
Visibility and memory model are very low level concerns created by the
library approach itself.

No. Java has an high level approach to concurrency (monitors
and synchronized methods), but still defines a memory model.
In fact the C++ memory model has been heavily inspired by Java.
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.

A library *alone* is not sufficient. The compiler must be aware of
threading for the program to work correctly. Even posix threads,
apparently a pure library solution put some requirements on the
compiler (see the recent try_lock discussion on the gcc mailing list).
E.g. ACE has been
rejected with this claim.
On the contrary, what we can see is that C++0x provides a purely
library-based approach for the threading,

How the memory model is a purely library based approach? How can you
implement atomic operations with a pure library extensions?
How can you be sure that a try_lock will work without the compiler
being is explicitly prohibited to perform speculative stores?
How can you be sure that the compiler doesn't move operations in or
out
of a critical section? C++0x is a language based approach. The
interface,
as most of C++0x appears as a library feature (and the idea is that it
could be implemented as such, as with little help from the compiler
as possible, but some help is needed).

BTW, the standard allows std::vector (or anything else in the standard
library) to be implemented as language construct!
however, on the other hand, C
++0x pays a great effort to (re)solve problems created by the library
approach.

You have to prove this claim.
Any decent concurrent programming language must provide some language
means to:
(1) mark the shared resources
(2) mark the associated Critical Regions

This is of course your opinion. Certainly C++ allows the second via
scoped_lock. You can do the first easily via encapsulation.
This way the compiler can and must check whether the shared resource
is accessed inside Critical Regions only.

But won't prevent you from deadlocking nor starving other threads or
many more common multithread problems. Letting your self blow up your
foot has always been C++ philosophy :)
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).

C++ is not (only) an OO language. And anyways, implementing a monitor
with std::condition_ variable and std::mutex (or whatever their names
are), is pretty trivial.

But with the tools C++0x will provide you can also build other
abstractions; for example in the multithread programming community
there
is some certain interest in the Join Calculus, and it would be
interesting to see it implemented in C++.
The checking function of the compiler can prevent a good deal of
concurrent programming errors 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.

I think this is considered a quality of implementation issue.
Producing
good thread debugging tools is very hard, and the standard does not
mandate a c++ compiler to implement them. You can get them from
a third party, but it is going to cost $$!
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.

You should be aware that just because these facilities have a library
interface in C++, it doesn't means that they aren't part of the
language.
The line between the library and the language is much tinnier in C++
than
in other languages.
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.

The previous two major C++ thread interfaces (Win32 threads and
POSIX threads) certainly are not a pure library based approach,
but their requirements on a compiler were a bit fuzzy or not
existent at all. C++0x took care to formalize that. There doesn't
seem to be any need to be beyond that. A pure language based solution
would mean: no lock-free data structures and algorithms, no (easy)
way to replace the compiler provided thread API, any user extension
would feel second class etc.
However, threading itself remains at the library-level. I
think we can summarise it that way, can't we.

Far from that.
P.S.: Once you know the details of the new proposal so well, would you
be so kind and publish some canonical concurrency problems solved in C+
+0x here, just to see how the proposal works out in some real code.http://groups.google.com/group/comp....07b37a3b0323f3
I do not know the details, I'm not a threading exert nor I have the
time
to write 'real code' for you.
Yes, it is clear from your whole answer that you are "not a threading
ex[p]ert".

On top of all that you clearly intermix the language level with the
library level. E.g. you keep saying that with help of scoped lock you
can implement a Critical Region. Well, I never doubted that.
Furthermore, I can implement a Critical Region with help of semaphores
too. I can implement even scoped locks or Monitors with help of
semaphores and without any visibility problem.---However, that depends
on pure discipline and it will never be a language level solution and
all the compiler support will be missing.

No problem if you cannot write 'real code' for us, never mind. I did
not address the request to you. You can find the questions addressed
to you in:
http://groups.google.com/group/comp....28af93a959bf75

Besides, I asked someone else, who seems to know the details, to put
some code fragments here. If you do not know the details *when* we
come to something exact to do, hmmm...., well---despite you talked a
lot about it creating the illusion as if you were in possession of the
details.

Anyway, thank you for your efforts. If you just do not have time to do
it, let us wait for the experts then.

Best Regards,
Szabolcs
Jun 27 '08 #29
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren ...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gm ail.comwrote:
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.
From 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:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #30

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

22
6607
by: Jorge Godoy | last post by:
Hi! I must have been searching in the wrong places or with the wrong keywords but I couldn't find out how to implement something such as what is done by the threading module on Windows (95, 98 and XP are the ones used by my clients). My preference is for something available in the standard library if possible. I have a simple task where I want my GUI to be able to open several
17
2455
by: Andrae Muys | last post by:
Found myself needing serialised access to a shared generator from multiple threads. Came up with the following def serialise(gen): lock = threading.Lock() while 1: lock.acquire() try: next = gen.next() finally:
4
4930
by: Joe Wong | last post by:
Hi, Is there any way to increase/decrease a thread priority in Python? Best regards, -- Wong
77
5402
by: Jon Skeet [C# MVP] | last post by:
Please excuse the cross-post - I'm pretty sure I've had interest in the article on all the groups this is posted to. I've finally managed to finish my article on multi-threading - at least for the moment. I'd be *very* grateful if people with any interest in multi-threading would read it (even just bits of it - it's somewhat long to go through the whole thing!) to check for accuracy, effectiveness of examples, etc. Feel free to mail...
5
1973
by: Roshan | last post by:
This is regarding the article titled "C++ & Double-Checked Locking" by Scott Meyers and Andrei in DDJ July 2004 issue. I think the reasoning in this article is fundamentally flawed due the authors mixing up a couple of concepts (observable behavior & side effects) that are defined separately in the standard. Background: In the following statement... class Singelton {
4
1268
by: Lionel van den Berg | last post by:
Hi all, I'm just wondering what's the best option for threading in C++? I've used pthreads and forking in C (the latter is not appropriate for my situation now). All I want to do is run a function in a new thread, it's a simple task, no interaction with other threads etc. so I don't have to worry about deadlock, starvation and so on. Thanks,
2
3275
by: Juuso Hukkanen | last post by:
I need a list of multithreading unsafe C (C99) functions/features. comp.programming.threads provided an initial list of C:ish functions, with following ANSI C functions: asctime, gmtime, localtime, ctime, tmpnam, strtok http://www.lambdacs.com/cpt/FAQ.html#Q150 However, extra Googling hinted rand() and srand(), also being unsuitable for multi-threading - opinions? And what is the status of
9
1870
by: cgwalters | last post by:
Hi, I've recently been working on an application which does quite a bit of searching through large data structures and string matching, and I was thinking that it would help to put some of this CPU-intensive work in another thread, but of course this won't work because of Python's GIL. There's a lot of past discussion on this, and I want to bring it up again because with the work on Python 3000, I think it is worth trying
1
4403
by: Seun Osewa | last post by:
Hello, I've tried to run several threading examples in Python 2.5.1 (with Stackless) For example: import threading theVar = 1 class MyThread ( threading.Thread ):
0
9994
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
11265
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10859
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10956
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10488
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9662
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
6079
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4298
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3309
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.