By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,454 Members | 1,804 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,454 IT Pros & Developers. It's quick & easy.

Threading in new C++ standard

P: n/a
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 #1
Share this Question
Share on Google+
126 Replies


P: n/a
Dann Corbit wrote:
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).
It's not a new way. Its from boost.

Click on the Link for n2497, scroll down and read:

"Acknowledgments
The overall design of this threading library is based on William Kempf's
Boost.Thread Library, as refined by literally hundreds of other Boost users
and contributors."

--
Thomas
http://www.netmeister.org/news/learn2quote.html
"Some folks are wise, and some otherwise."
Jun 27 '08 #2

P: n/a
Sam
Dann Corbit writes:
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
Perhaps because not everyone shares your enthusiasm for ACE?
the same way that the STL (and subsequently BOOST) have been subsumed?
Boost is not universally liked either. As the saying goes: just because
everyone decides to jump off a cliff, should you follow?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBIBTuRx9p3GYHlUOIRAs8pAJ4mbo/nlrRALBXE17a1LAY0Yz8VIQCfX8Zu
wpfbinv1/+hc7LVtnDL9zsA=
=WbVf
-----END PGP SIGNATURE-----

Jun 27 '08 #3

P: n/a
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
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?
There are serious problems with the model ACE uses.
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).
It's not actually used on "zillions of platforms"---as far as I
know, it supports Windows and Unix, and that's about it.

ACE is somewhat dated, and uses what was the classical model for
thread objects at the time it was developed. The general
concensus today is that this model isn't really that
appropriate, at least for a language with value semantics like
C++.

The second aspect is that ACE (and Boost, which represents a
more "state of the art" model) only address one of the reasons
threading is desired, and don't effectively support uses like
parallelizing, which are becoming important with the diffusion
of multicore machines.
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
I think we're still largely at the beginning when it comes to
knowing the best idioms to support threading. Rather than
standardize something experimental, which later turns out to be
far less than ideal, I think we should only standardize an
essential minimum, on which people can build and experiment.

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #4

P: n/a
On Apr 16, 1:12 am, "Thomas J. Gritzan" <Phygon_ANTIS...@gmx.de>
wrote:
Dann Corbit wrote:
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).
It's not a new way. Its from boost.
Click on the Link for n2497, scroll down and read:
"Acknowledgments
The overall design of this threading library is based on
William Kempf's Boost.Thread Library, as refined by literally
hundreds of other Boost users and contributors."
Boost only represents a small part of threading in the standard.
Significant parts of the interface will doubtlessly profit from
the experience we've gotten with Boost; other parts are designed
to address lower level threading issues. And of course, Boost
more or less ignored the language issues (you get whatever the
platform gives), which are the most important in a standard.

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #5

P: n/a
Hi James,
>There are serious problems with the model ACE uses.
ACE supports several threading models. Can you please elaborate on
these problems?
>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).

It's not actually used on "zillions of platforms"---as far as I
know, it supports Windows and Unix, and that's about it.
ACE has been ported to many more platforms than Windows and Unix,
though not surprisingly those are the most common platforms on which
it's used. Please see

http://www.dre.vanderbilt.edu/~schmi...html#platforms

for more info on platforms that ACE has been ported to and the
status of these ports. The status of the builds on the most commonly
used platforms is available in real-time from

http://www.dre.vanderbilt.edu/scoreb...ntegrated.html

Thanks,

Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.*******@vanderbilt.edu
Jun 27 '08 #6

P: n/a
On Apr 15, 3:28 pm, "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
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).
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=180936and Boehm's article of "threads cannot be
implemented as a library").

Second, ACE folks tried to sell it to standard bodys few years ago.
However, instead of going to a language or platform standard
organization (such as relevant committees in ANSI, ISO, IEEE, and
OpenGroup), they went to OMG (see the discussion in this thread
http://groups.google.com/group/comp....b3a5630b1882a).

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

** Posted fromhttp://www.teranews.com**
Jun 27 '08 #7

P: n/a
On Apr 16, 5:39 am, schm...@tango.dre.vanderbilt.edu (Douglas C.
Schmidt) wrote:
Hi James,
There are serious problems with the model ACE uses.

ACE supports several threading models. Can you please elaborate on
these problems?
See http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf

Ke
Jun 27 '08 #8

P: n/a
"Dann Corbit" <dc*****@connx.comwrote in message
news:52******************@news.teranews.com...
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
Check this out:

http://groups.google.com/group/comp....e27f5e0570910d
Here is how to completely live-lock their STM:

http://groups.google.com/group/comp....a8ed18e97130b2
It's no where near ready for prime time. STM has issues with scalability and
live-lock.

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
This is _very_ misleading to say the least. They only talk about live-lock
in terms of transactions getting invalidated by other low-priority
transactions. This is definitely not the only way to live-lock a STM.

Here is just one of many ways:

http://groups.google.com/group/comp....356c832812213b


STM have a whole lot of scaling issues. Here are some of them:

http://groups.google.com/group/comp....ef56a090c052d9
Its no silver-bullet indeed. I would go with distributed message-passing
over STM any day.

Jun 27 '08 #9

P: n/a
On 16 avr, 14:39, schm...@tango.dre.vanderbilt.edu (Douglas C.
Schmidt) wrote:
Hi James,
There are serious problems with the model ACE uses.
ACE supports several threading models. Can you please
elaborate on these problems?
Or no model; like most other libraries, it's just a wrapper for
whatever the implementation gives you.

Seriously, what I was referring to was the fact that you have
(or had, at least) a Thread class, from which the user had to
derive. This was, of course, the accepted practice when ACE
first appeared, but we've found better solutions since then.

There's also the problem, IIRC, that there is no real
distinction between detached threads and joinable threads. (Of
course, ACE isn't alone in that:-).)

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #10

P: n/a
On 16 avr, 18:21, Ke Jin <kjin...@gmail.comwrote:
On Apr 15, 3:28 pm, "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
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).
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=180936and Boehm's article of "threads
cannot be implemented as a library").
I don't think that that's entirely the problem. There are
different levels of standardizing threads---ACE, like Boost, and
all of the other threading libraries I've seen for C++, seem to
content themselves with just defining a more or less "standard"
interface to whatever the OS offers. They don't address the
language level problems, nor do they attempt to (nor can they,
really).

The standard, obviously, has to, and threading is more than just
a library issue in the standard. But the standard also has to
address the interface: how the user starts a thread,
synchronizes different threads, etc. And that is a library
issue.

IMHO, there is a serious problem at this level. I don't think
that the actual technologies are mature enough. Every new
library which comes out does it differently, and we don't have
enough experience with any of them to really say what is best.
On the other hand, politically, it is a must if C++ is to
survive and prosper. So we'll do the best we can, and hope that
whatever we do won't cause problems down the road, when we have
some real experience under our belts.

(It's worth pointing out that while normally, a standard should
only standardize existing practice, in this case, the "existing
practice" is that most threaded programs have subtle bugs, and
don't work correctly in some special cases.)

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #11

P: n/a
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
...
Are there some examples available in this new notation?

Can someone demonstrate here some canonical examples in this new
proposed
notation?

- Producer-consumer problem (bounded buffer)
- Readers and writers problem
- Dining philosophers problem
- Sleeping barber problem
- Santa Claus problem (http://stwww.weizmann.ac.il/g-cs/benari/
articles/santa-claus-problem.pdf)

It would be interesting to see how the proposal works out.

Best Regards,
Szabolcs
Jun 27 '08 #12

P: n/a
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_variable):

<quote>
template <class Predicate>
void wait(unique_lock<mutex>& lock, Predicate pred);
Effects:
As if:
while (!pred())
wait(lock);
</quote>

Now programming the get operation of a bounded buffer would look
something like this, I guess:

queue BB::q;
mutex BB::m;
condition_variable BB::empty;
condition_variable BB::full;
int BB::get()
{
int b;
unique_lock<mutexlock(m);
full.wait(lock, !q.empty());
b = q.get();
empty.notify_one();
return b;
}

Although there is still some duplication in `full.wait(lock, !
q.empty());', it is much closer to this simple pseudo code (where
`when' is a keyword for a conditional critical region statement) than
a pthread version:

shared queue BB::q;
int BB::get()
{
int b;
when (!q.empty()) {
b = q.get();
}
return b;
}

Best Regards,
Szabolcs
Jun 27 '08 #13

P: n/a
Hi James,

Thanks for providing some additional info.
Or no model; like most other libraries, it's just a wrapper for
whatever the implementation gives you.
That's not entirely the case, e.g., the ACE_Thread_Manager is more
than just a wrapper over the underlying implementation. Naturally, if
the OS doesn't support threads at all it's hard for a library-based
implementation to do much about this..
Seriously, what I was referring to was the fact that you have (or
had, at least) a Thread class, from which the user had to derive.
I assume you're referring to ACE_Task here? It implements an Active
Object model that's similar to Java's Thread class + a synchronized
message queue.
This was, of course, the accepted practice when ACE first appeared,
but we've found better solutions since then.
Can you please point to some descriptions of these solutions?
There's also the problem, IIRC, that there is no real distinction
between detached threads and joinable threads.
It's not clear what you mean by this - can you please explain? The
ACE_Thread_Manager implements both detached and joinable threads atop
all the underlying operating systems, not just POSIX pthreads.

Thanks,

Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.*******@vanderbilt.edu
Jun 27 '08 #14

P: n/a
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:EL******************************@comcast.com. ..
"Dann Corbit" <dc*****@connx.comwrote in message
news:52******************@news.teranews.com...
>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

Check this out:

http://groups.google.com/group/comp....e27f5e0570910d
Here is how to completely live-lock their STM:

http://groups.google.com/group/comp....a8ed18e97130b2
It's no where near ready for prime time. STM has issues with scalability
and live-lock.

>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

This is _very_ misleading to say the least. They only talk about live-lock
in terms of transactions getting invalidated by other low-priority
transactions. This is definitely not the only way to live-lock a STM.

Here is just one of many ways:

http://groups.google.com/group/comp....356c832812213b


STM have a whole lot of scaling issues. Here are some of them:

http://groups.google.com/group/comp....ef56a090c052d9
Its no silver-bullet indeed. I would go with distributed message-passing
over STM any day.
I was not aware of the shortfalls of the STM approach, having only read
glowing reviews. Thanks for the pointers. I was going to download and try
the Intel compiler (but was foiled by the Java interface) so I think I will
halt efforts in that direction until things shake out more thoroughly.
** Posted from http://www.teranews.com **
Jun 27 '08 #15

P: n/a
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:24**********************************@d1g2000h sg.googlegroups.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_variable):
[...]

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

Jun 27 '08 #16

P: n/a
"Dann Corbit" <dc*****@connx.comwrote in message
news:57******************@news.teranews.com...
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:EL******************************@comcast.com. ..
[...]
>STM have a whole lot of scaling issues. Here are some of them:
[...]
>>
Its no silver-bullet indeed. I would go with distributed message-passing
over STM any day.

I was not aware of the shortfalls of the STM approach, having only read
glowing reviews. Thanks for the pointers.
No problem. Unfortunately, 99% of the STM research papers seem to
continently leave out a list of caveat's. IMHO, STM is a good tool to have
around, but its not the "silver-bullet" that most of the papers hint at. You
can make some good use out of a STM, but you have to be really careful, and
know exactly what your doing inside those atomic-blocks. If you make poor
decisions in those transactional atomic-blocks, your going to get burned by
scaling issues and sporadic periods of live-lock during periods of high, or
even moderate, load on the system.

I was going to download and try the Intel compiler (but was foiled by the
Java interface) so I think I will halt efforts in that direction until
things shake out more thoroughly.
Yeah. I would lurk around their forum and study some of the discussions
going on in there. One post in particular caught my eye:

http://softwarecommunity.intel.com/i.../30248420.aspx
Here is the exact response that Haris Volos got from Jim Cownie who works in
the lab where this experimental development is being conducted:
"What semantics are you expecting from transactions?
If you consider them to have the same semantics as a single global lock,
then this code clearly deadlocks, so it is no big surprise that it can also
deadlock with TM..."
He is telling the truth indeed.

Jun 27 '08 #17

P: n/a
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=180936>
and Boehm's article of "threads cannot be
implemented as a library").
Is not "Multi-threading Library for Standard C++" just another
library?

I cannot see the language features for concurrency but only the
library ones. For instance, you can instantiate a thread from a
library class. There is no language element for defining a thread, is
there?

There is no keyword in C++0x to mark the shared data. Consequently the
compiler will not be able to check whether the shared data is accessed
properly inside critical region or not.

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 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/wg...thread.threads

Perhaps someone can help me out.

Best Regards,
Szabolcs
Jun 27 '08 #18

P: n/a
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=180936>
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?
>
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) is the
introduction of a (quite advanced, BTW) memory model, which is a
*pure* language feature.
Also it introduces atomic operations which must be implemented at
the language level.

Everything else is pretty much just standardizing pretty the status
quo.
For instance, you can instantiate a thread from a
library class. There is no language element for defining a thread, is
there?
So what?
>
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.
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.
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'
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. The standard
committee mostly
standardizes what already exists and tries to introduce as little
(untested)
innovations as possible.

--
Giovanni P. Deretta
Jun 27 '08 #19

P: n/a
On Apr 17, 9:25 pm, schm...@tango.dre.vanderbilt.edu (Douglas C.
Schmidt) wrote:
Or no model; like most other libraries, it's just a wrapper for
whatever the implementation gives you.
That's not entirely the case, e.g., the ACE_Thread_Manager is
more than just a wrapper over the underlying implementation.
Naturally, if the OS doesn't support threads at all it's hard
for a library-based implementation to do much about this..
What I meant is that you don't really define when external
synchronization is needed, and when it isn't. Under Posix,
external synchronization is needed when Posix says it's needed,
and under Windows, when Windows says it's needed.

This is the aspect which really has to be treated at the
language level: what does a "sequence point" mean in a
multithreaded environment? There are also library aspects: when
do I need external synchronization when using library components
in two different threads.
Seriously, what I was referring to was the fact that you
have (or had, at least) a Thread class, from which the user
had to derive.
I assume you're referring to ACE_Task here? It implements an
Active Object model that's similar to Java's Thread class + a
synchronized message queue.
And Java's Thread class is an example of a poorly designed
interface for threading. At least today; it was pretty much
standard practice when it appeared, but we've learned a lot
since then. And are still learning: I'm not sure that even
today, threading technology is mature enough to be technically
ready for standardization. (But politically, we don't have a
choice. If the next version of the C++ standard doesn't address
threading, the language is probably dead.)
This was, of course, the accepted practice when ACE first
appeared, but we've found better solutions since then.
Can you please point to some descriptions of these solutions?
Boost offers parts of them. The whole concept of functional
objects changes the situation considerably.

IMHO, too, what I've learned from practical experience is that
joinable threads and detached threads are two very different
beasts. For detached threads, the best solution I've found so
far is a template function, something more or less like:

template< typedef Function >
void
startDetachedThread(
Function f )
{
boost::thread( f ) ;
}

Fire and forget, in sum, with copy semantics handling all of the
memory management issues.

For joinable threads, you still want the thread class to take
the functional object as an argument (so that you're ensured
that it fully constructed before the thread starts). In Java,
for example, deriving from java.lang.Thread is a common source
of errors (which don't occur if you pass a Runnable to the
constructor of Thread). In C++, the issue is further
complicated by memory management issues, since there's no
garbage collection. (I don't think that they're necessarily
difficult issues, and I suspect that there are several
acceptable solutions. But they do have to be addressed.)

I'm not really too sure how ACE handles this; it's been a long
time since I last looked at it (and it may have evolved since
then).

I'm also not too sure how (or if) ACE handles propagation of an
exception accross a join. It's important that the standard
offer some sort of support for this as well. Although I don't
think it should be the default, and it doesn't bother me if it
requires some programming effort to get, it is currently
impossible to implement in Boost, and I suspect in any other
threading system (since it also requires some language support,
which isn't there at present).
There's also the problem, IIRC, that there is no real
distinction between detached threads and joinable threads.
It's not clear what you mean by this - can you please explain?
The ACE_Thread_Manager implements both detached and joinable
threads atop all the underlying operating systems, not just
POSIX pthreads.
But do you even need a thread manager for detachable threads.

Note that I'm talking here about the lowest level; the one which
must be in the standard. There's definitely place for more
elaborate (and less general) models at a higher level.

With regards to standardization, what ACE has going for it, of
course, is the fact that it probably has more users than all
other systems combined, and we have a lot of concrete experience
with it. What it has going against it is its age (it doesn't
take into account all of the changes in programming style in the
last years), and the fact that no one in the committee is
championing it. (The Boost group are very active in
standardization. You and others working on ACE don't seem to be
so.)

What all existing libraries have going against them (IMHO) is
that the "existing practice" with regards to threads is that
most multi-threaded programs don't actually work, or won't if
the active thread changes at the wrong moment, of if they're
ported to a multi-processor system, or if any one of a number of
other things occur. From a technical point of view, this means
that it's probably too early to standardize threading this go
round. From a political point of view, however, I don't think
we have a choice.

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #20

P: n/a
On Apr 17, 11:31 pm, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:24**********************************@d1g2000h sg.googlegroups.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_variable):
[...]
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.comcast.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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #21

P: n/a
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=180936>
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

P: n/a
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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #23

P: n/a
On Apr 19, 9:25*am, James Kanze <james.ka...@gmail.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

P: n/a
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:5b**********************************@c58g2000 hsc.googlegroups.com...
On Apr 19, 9:25 am, James Kanze <james.ka...@gmail.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

P: n/a
On 19 avr, 20:03, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 19, 9:25 am, James Kanze <james.ka...@gmail.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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #26

P: n/a
On Apr 20, 10:33*am, James Kanze <james.ka...@gmail.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

P: n/a
On Apr 20, 1:42 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gmail.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_lock (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

P: n/a
On Apr 20, 3:45*pm, gpderetta <gpdere...@gmail.comwrote:
On Apr 20, 1:42 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gmail.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_lock (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

P: n/a
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 10:33 am, James Kanze <james.ka...@gmail.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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #30

P: n/a
On 2008-04-20 12:36:50 -0400, James Kanze <ja*********@gmail.comsaid:
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.
There actually was a proposal for threading at the language level:
http://www.open-std.org/jtc1/sc22/wg...005/n1875.html.
But, as you say, that is contrary to the basic principles of C++.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jun 27 '08 #31

P: n/a
On Apr 20, 6:36*pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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).
So, you say "threading issues will be addressed in the language."
Good. Let us see. Now, please tell me, just to make some sense:

(1) How you can start a thread of computation in C++0x? Do you have a
language element for it, or do you have just some library stuff?

(2) How can you define mutual exclusion for the concurrent threads of
computations in C++0x? Do you have a language element for it, or do
you have just some library stuff?

(3) How can you make threads synchronised with each other? Do you have
a language element for it, or do you have just some library stuff?

Please try to answer these questions. If you sincerely answer them we
can see whether C++0x addresses threading at the language level or at
the library level.

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 #32

P: n/a
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:cd**********************************@l42g2000 hsc.googlegroups.com...
[...]
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
Here is dining philosophers problem solved with POSIX Threads and C:

http://appcore.home.comcast.net/misc/diner_c.html

Its going to be absolutely trivial to implement that in C++0x because it
offers everything one needs to do it.
Here is are some full-blown reader-writer solution in x86:

http://appcore.home.comcast.net/misc...mple_h_v1.html
(Proxy GC implementation...)

http://appcore.home.comcast.net
(SMR implementation...)
Luckily C++0x is going to provide all the atomics and membars needed to
implement those algorithms. Even the first one (e.g., proxy gc)... It
requires DWCAS, however, C++0x is low-level enough for me to use alignment
and offset tricks to elude its use. The threading tools provided in C++0x
will allow one to code solutions to all the problems you listed.

Finally, C++0x will allow somebody to create 100% standard implementations
of many state-of-the-art synchronization algorithms. That's a good thing
indeed!

:^)

Jun 27 '08 #33

P: n/a
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:7c**********************************@24g2000h sh.googlegroups.com...
On Apr 20, 6:36 pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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).
So, you say "threading issues will be addressed in the language."
Good. Let us see.
Your not grasping the concept. POSIX Threads implementations are implemented
as a library, however, a conforming C compiler MUST comply with the
restrictions that the PThread standard imposes on it. You can read a VERY
brief description from Mr. PThread himself:

http://groups.google.com/group/comp....9f412608a8570d

;^)

Here is what happens when a compiler does not follow the rules imposed by
POSIX Threads:

http://groups.google.com/group/comp....f6360d939612b3

This is not a legal optimization for a compiler to perform IF it claims that
it works with POSIX systems.

Now, please tell me, just to make some sense:
(1) How you can start a thread of computation in C++0x? Do you have a
language element for it, or do you have just some library stuff?
std::thread

(2) How can you define mutual exclusion for the concurrent threads of
computations in C++0x? Do you have a language element for it, or do
you have just some library stuff?
std::mutex

(3) How can you make threads synchronised with each other? Do you have
a language element for it, or do you have just some library stuff?
std::condition_variable
std::atomic

Please try to answer these questions. If you sincerely answer them we
can see whether C++0x addresses threading at the language level or at
the library level.
It address threading at both the language and library level.

[...]

Jun 27 '08 #34

P: n/a
On 20 Apr., 19:17, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 6:36*pm, James Kanze <james.ka...@gmail.comwrote:
[snip]
So, you say "threading issues will be addressed in the language."
Good. Let us see. Now, please tell me, just to make some sense:

(1) How you can start a thread of computation in C++0x? Do you have a
language element for it, or do you have just some library stuff?

(2) How can you define mutual exclusion for the concurrent threads of
computations in C++0x? Do you have a language element for it, or do
you have just some library stuff?

(3) How can you make threads synchronised with each other? Do you have
a language element for it, or do you have just some library stuff?
Well... instead of persevering with your questions, I really believe
that you should try to read the Böhm paper. If not for your own sake,
then for ours ;-)
The answer to your questions above is obvious (it is in a library),
but this still does not change the fact that threading for a large
part is a language issue.

/Peter
Jun 27 '08 #35

P: n/a
On Apr 20, 6:36*pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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.
From what you understand, maybe yes. I must tell you that there was
life before Ada in the area of concurrent programming and there are
other genuine concurrent programming languages than Ada. But Ada was
certainly the state of the art concurrent programming language at a
time.

However, the multi-core boom was not there yet.
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++.
Funny indeed. C++ is a pure sequential programming language but Ada is
a high level concurrent programming language tackling concurrency at
the language level. How can you compare them from the concurrency
point of view?

Concurrent programs has nothing to do with C++ so far since you are
just working on the enhancement of C++.

Consequently, concurrent programs in Ada CANNOT have exactly the same
problems as those in C++. It would be funny, indeed.

Best Regards,
Szabolcs
Jun 27 '08 #36

P: n/a
On Apr 21, 1:14 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 6:36 pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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.
From what you understand, maybe yes. I must tell you that
there was life before Ada in the area of concurrent
programming and there are other genuine concurrent programming
languages than Ada. But Ada was certainly the state of the art
concurrent programming language at a time.
I'm aware of that. Since then, the state of the art has moved
on, and the Ada model is really considered a bit too
constricting.
However, the multi-core boom was not there yet.
Maybe not in your world. I had to deal with parallel processors
in some of my work in the late 1970's. During the eighties, the
automation of parallel processing was the rage in compilers.
It's only recently that such parallelism has descended to the
PC's, but it's hardly new.
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++.
Funny indeed. C++ is a pure sequential programming language
but Ada is a high level concurrent programming language
tackling concurrency at the language level. How can you
compare them from the concurrency point of view?
Why not? You have exactly the same problems writing correct
multithreaded code in Ada as you do in C or C++ under Posix.
Concurrent programs has nothing to do with C++ so far since
you are just working on the enhancement of C++.
Consequently, concurrent programs in Ada CANNOT have exactly
the same problems as those in C++. It would be funny, indeed.
Except that they do. The suffer from deadlocks, and race
conditions, and all of the same problems C and C++ programs
suffer from.

Welcome to the real world.

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #37

P: n/a
On Apr 20, 7:17 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 6:36 pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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).
So, you say "threading issues will be addressed in the language."
Good. Let us see. Now, please tell me, just to make some sense:
(1) How you can start a thread of computation in C++0x? Do you have a
language element for it, or do you have just some library stuff?
(2) How can you define mutual exclusion for the concurrent threads of
computations in C++0x? Do you have a language element for it, or do
you have just some library stuff?
(3) How can you make threads synchronised with each other? Do you have
a language element for it, or do you have just some library stuff?
You don't seem to be reading what I am writing. These are not
fundamental threading issues; they're simply means of accessing
the underlying thread model. Since they're just an API, they
are naturally defined in the library; it would be a serious
design error to do otherwise.

The real threading issue is rather when you need 2, and when you
need 3 (and of course, when memory is synchronized between
different threads), not how you access the primitives which
provide them. And that is a pure language issue.

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #38

P: n/a
On Apr 20, 6:22 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 3:45 pm, gpderetta <gpdere...@gmail.comwrote:
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".
Yes, I'm not a self-appointed threading expert.
>
On top of all that you clearly intermix the language level with the
library level.
In c++ the library level and the language *are* intermixed.
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.
How do you know that your compiler is not going to optimize around
your semaphore? I, and pretty much everybody else, claim that it
is impossible to write a correct semaphore class in ISO C++. Not
without extra help from the compiler.
---However, that depends
on pure discipline and it will never be a language level solution and
all the compiler support will be missing.
After lot's of talking you still fail to explain us how a
keyword based interface would be better than a library based
interface.

--
Giovanni P. Deretta
Jun 27 '08 #39

P: n/a
Szabolcs Ferenczi wrote:
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.
Szabolcs,

I think you are referring to my original post. To clarify, I didn't
claim that ACE had been rejected for this reason. I was just pointing
out that the C++0x thread goes beyond ACE thread.

Second, I am not aware of ACE has ever been submitted to C++0x, not to
mention it was rejected for any reason. In fact, I pointed out in my
original post that ACE folks did attempt to have it stamped by a
standard organization. However, instead of pursuing ANSI or ISO
(therefore C++0x committee) suggested by us, they went to OMG (see the
link in the original post).

Regards,
Ke
Jun 27 '08 #40

P: n/a
On Apr 21, 10:45*am, James Kanze <james.ka...@gmail.comwrote:
On Apr 21, 1:14 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
However, the multi-core boom was not there yet.

Maybe not in your world.
Not in your world either unless you are dreaming.
>*I had to deal with parallel processors
in some of my work in the late 1970's.
I do not doubt that you did. Well done.

However, it is not an argument against that at the time Ada was
designed the multi-core boom was not there yet. That is what I said.
You are going against the facts, I must tell you.
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++.
Funny indeed. C++ is a pure sequential programming language
but Ada is a high level concurrent programming language
tackling concurrency at the language level. *How can you
compare them from the concurrency point of view?

Why not?
Just because Ada is a concurrent programming language with proper
language means for concurrency. C++ is not one---today. That is why.
Simple, isn't it?
>*You have exactly the same problems writing correct
multithreaded code in Ada as you do in C or C++ under Posix.
Well, on the same ground you can tell that the problem applies to any
meaningful concurrent programming languages today. Not to C++,
however, since it is not a concurrent programming language as far as
the language level is concerned. And it does not want to be one too.

Concurrency library + adjusted sequential language != concurrent
language

You can make programs in the combination of library and a hacked
sequential language, of course, but the compiler support is missing
for the concurrent parts. I am not talking about optimisation because
it is not compiler support. I am talking about the compiler checking
the correct use of the shared resources. For that, however, you should
be able to mark the shared resources and the cirtical regions at the
language level.
Concurrent programs has nothing to do with C++ so far since
you are just working on the enhancement of C++.
Consequently, concurrent programs in Ada CANNOT have exactly
the same problems as those in C++. It would be funny, indeed.

Except that they do.
Today C++ is a pure sequential programming language without any
language elements for concurrency. I hope you can admit that. Ada on
the other hand is a concurrent language with proper language means for
concurrency. Consequently, programs written in the two language cannot
have the same concurrency problems since one of the languages is
sequential.
>*The suffer from deadlocks, and race
conditions, and all of the same problems C and C++ programs
suffer from.

Welcome to the real world.
In the real world C and C++ programs only suffer from their low level
features like pointers and their type system. Concurrency at the
language level has nothing to do with either C or C++, and as it looks
like, it never will be.

That is the real world.

I hope I could help.

Best Regards,
Szabolcs
Jun 27 '08 #41

P: n/a
On Apr 20, 6:36*pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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.
Do you think it is necessary for you go to that level? Let me ignore
your attempt of personal insult.
>*Boehm's point, which has been accepted by the committee,
is that you have to address certain threading issues at the
language level.
Yes, he only deals with the situation what follows when you introduce
library level means. My point was that Boehm did not addressed the
important issue what is the fundamental difference having something at
the language level or at the library level.

See: "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."
>*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.
You have been unveiled already in this blunder by someone who is
involved in C++0x:
http://groups.google.com/group/comp....a5fdf80fd7f461

Best Regards,
Szabolcs
Jun 27 '08 #42

P: n/a
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:29**********************************@m73g2000 hsh.googlegroups.com...
On Apr 20, 6:36 pm, James Kanze <james.ka...@gmail.comwrote:
On 20 avr, 13:42, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
...
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.
Do you think it is necessary for you go to that level? Let me ignore
your attempt of personal insult.
It sounds like your trying to say that C++0x is no good because it won't
have very high-level keywords which deal with automatic critical sections
and the like... If that it true, well, your a bit misguided to say the
least...

Boehm's point, which has been accepted by the committee,
is that you have to address certain threading issues at the
language level.
Yes, he only deals with the situation what follows when you introduce
library level means. My point was that Boehm did not addressed the
important issue what is the fundamental difference having something at
the language level or at the library level.
He did not need to go into that. He was trying to point out that C++ can use
threads if the compilers follow some specific rules. Much like the rules
POSIX Threads puts on C compilers. Your not getting the fact that the
library and language wrt threads needs have a very intimate relationship
with each other. C++ does not need any new keywords to implement threading.

See: "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."
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.
You have been unveiled already in this blunder by someone who is
involved in C++0x:
http://groups.google.com/group/comp....a5fdf80fd7f461
Huh? Please explain how your 'shared' keyword would allow me to program an
OS kernel which depends on asynchronous signal-safe atomic operations and
fine-grain memory barriers for use in interrupt handlers? How could I use
your 'shared' keyword to program RCU? IMHO, you keyword would break the
spirit of C++.

Jun 27 '08 #43

P: n/a
On Apr 21, 6:52*pm, Ke Jin <kjin...@gmail.comwrote:
Szabolcs Ferenczi wrote:
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.

Szabolcs,

I think you are referring to my original post. To clarify, I didn't
claim that ACE had been rejected for this reason. I was just pointing
out that the C++0x thread goes beyond ACE thread.
Hi Ke,

I do not refer specifically to your post it is just an accident that
my comment to your post has somehow attracted some forum fighters.

I remember having seen a number of arguments that day going that the
library solution is not adequate (with reference to the paper of
Boehm) and that C++0x goes for a language-based approach instead.
(Unfortunately, Google could have some problem that day since some
posts have disappeared from the web pages.) Having heard that C++0x
tackles threading at the language level I became quite enthusiastic
but when I checked into the document
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
I had to conclude that C++0x also has a pure library approach as far
as threading is concerned.

I was also searching for some language elements for concurrency in the
document but all I could find was just library stuff. When I wanted to
learn from the forum members about the exact language _elements_ in C+
+0x, I got _elementary_ attack instead.

That C++0x will have threading at the library level is not good but
that alone is not a big problem. Only it will just not be any
different from the other languages which have threading at the library
level, including Java. But then, after all, ACE is a library too.

That C++0x will have threading at the library level as well is not a
problem, at least not if people are aware of it. I could not get it
acknowledged here that threading is at library level in C++0x. Well,
some people here often refer to the development in threading in the
last ten years and claiming some state-of-the-art threading which is
missing from ACE. There is development in the hardware side, I think,
but there is hardly any development or rather there is a retrogression
in the software side as far as concurrent programming is concerned.
With the current trend in C++ it will just continue, I guess.
Second, I am not aware of ACE has ever been submitted to C++0x, not to
mention it was rejected for any reason. In fact, I pointed out in my
original post that ACE folks did attempt to have it stamped by a
standard organization. However, instead of pursuing ANSI or ISO
(therefore C++0x committee) suggested by us, they went to OMG (see the
link in the original post).
Perhaps ACE itself was not submitted and neither rejected, I do not
know it either. I am not especially an ACE fan. I just remembered some
claim like library itself is not an approach C++0x goes, but what I
can see in the doc is just library stuff.

So I just wanted to learn from some experts here what are the language
elements then in C++0x with respect to threading. Sadly, I could not
find any competent person here, except for some enthusiastic forum
fighters, it seems.

Best Regards,
Szabolcs
Jun 27 '08 #44

P: n/a
On Apr 20, 11:12*pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 20 Apr., 19:17, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 6:36*pm, James Kanze <james.ka...@gmail.comwrote:

[snip]
So, you say "threading issues will be addressed in the language."
Good. Let us see. Now, please tell me, just to make some sense:
(1) How you can start a thread of computation in C++0x? Do you have a
language element for it, or do you have just some library stuff?
(2) How can you define mutual exclusion for the concurrent threads of
computations in C++0x? Do you have a language element for it, or do
you have just some library stuff?
(3) How can you make threads synchronised with each other? Do you have
a language element for it, or do you have just some library stuff?

Well... instead of persevering with your questions,
Why don't you dare to face those simple questions?
I really believe
that you should try to read the Böhm paper. If not for your own sake,
then for ours ;-)
Of course I have read it already before I have made my first
contribution to this discussion thread. Interesting that anyone, who
cannot find any argument himself, calls me to read that article.

Now I must tell you that Boehms article tackes the problem in a wrong
way. He consideres the situation where shared variables are not
accessed in a mutually exclusive way and tries to draw conclusion from
it. I have a good feeling that all of his three examples (Section 4)
are inadequate (buggy) from the concurrent prgramming point of view.

Already in the 60s it was clear, that whenever concurrent processes
share some variables, i.e. they may access them simultaneously so that
one of the processes changes it, those variables must be protected by
critical sections.

For an example see Section 3 in Boehm:

<quote>
Thus if we started in an initial state in which all variables are
zero, and one thread executes:
x = 1; r1 = y;
while another executes
y = 1; r2 = x;
either the assignment to x or the assignment to y must be executed
first, and either r1 or r2 must have a value of 1 when execution
completes.
... Essentially all re-alistic programming language implementations
supporting
true concurrency allow both r1 and r2 to remain zero in the above
example.
</quote>

Since variables `x' and `y' are accessed in both threads, i.e. they
are shared ones, it is evident that Boehm's example simply has a
concurrent bug. As soon as the bug is fixed (by an embracing critical
region) Boehm's problem disappears.

E.g. if `cr' means critical region (or you can use mutexes):
cr{ x = 1; r1 = y; }
cr{ y = 1; r2 = x; }

You would see the same symptom in Section 4 as well (4.2 is perhaps a
corner case). The whole discussion is built on the assumption: what if
you do not know how to write a correct concurrent program and you use
shared variables without any protection.

I suggest you to study concurrent programming and then re-read the
Boehm paper. You will be surprised.
The answer to your questions above is obvious (it is in a library),
At least someone who can admit the obvious.
but this still does not change the fact that threading for a large
part is a language issue.
It should be a language issue but where are those language elements in
C++0x? You say it is a large part of it. It is fact, you say. Can you
show here just a small part of it? Factually.

Best Regards,
Szabolcs
Jun 27 '08 #45

P: n/a
"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:68977d32-c840-4029-a3f1->
df**********@r66g2000hsg.googlegroups.com...
On Apr 20, 11:12 pm, peter koch <peter.koch.lar...@gmail.comwrote:
On 20 Apr., 19:17, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 20, 6:36 pm, James Kanze <james.ka...@gmail.comwrote:
[snip]
So, you say "threading issues will be addressed in the language."
Good. Let us see. Now, please tell me, just to make some sense:
(1) How you can start a thread of computation in C++0x? Do you have a
language element for it, or do you have just some library stuff?
(2) How can you define mutual exclusion for the concurrent threads of
computations in C++0x? Do you have a language element for it, or do
you have just some library stuff?
(3) How can you make threads synchronised with each other? Do you have
a language element for it, or do you have just some library stuff?
Well... instead of persevering with your questions,

Why don't you dare to face those simple questions?
You are completely misguided!

:^|

I really believe
that you should try to read the Böhm paper. If not for your own sake,
then for ours ;-)
Of course I have read it already before I have made my first
contribution to this discussion thread. Interesting that anyone, who
cannot find any argument himself, calls me to read that article.
Now I must tell you that Boehms article tackes the problem in a wrong
way. He consideres the situation where shared variables are not
accessed in a mutually exclusive way and tries to draw conclusion from
it. I have a good feeling that all of his three examples (Section 4)
are inadequate (buggy) from the concurrent prgramming point of view.

Already in the 60s it was clear, that whenever concurrent processes
share some variables, i.e. they may access them simultaneously so that
one of the processes changes it, those variables must be protected by
critical sections.
Ever heard of non-blocking algorithms?

For an example see Section 3 in Boehm:
<quote>
Thus if we started in an initial state in which all variables are
zero, and one thread executes:
x = 1; r1 = y;
while another executes
y = 1; r2 = x;
either the assignment to x or the assignment to y must be executed
first, and either r1 or r2 must have a value of 1 when execution
completes.
... Essentially all re-alistic programming language implementations
supporting
true concurrency allow both r1 and r2 to remain zero in the above
example.
</quote>
Since variables `x' and `y' are accessed in both threads, i.e. they
are shared ones, it is evident that Boehm's example simply has a
concurrent bug. As soon as the bug is fixed (by an embracing critical
region) Boehm's problem disappears.
E.g. if `cr' means critical region (or you can use mutexes):
cr{ x = 1; r1 = y; }
cr{ y = 1; r2 = x; }
You would see the same symptom in Section 4 as well (4.2 is perhaps a
corner case). The whole discussion is built on the assumption: what if
you do not know how to write a correct concurrent program and you use
shared variables without any protection.
I suggest you to study concurrent programming and then re-read the
Boehm paper. You will be surprised.
I suggest you learn about low-level high-performance multi-threading
algorithms. C++ will have efficient support for them in the form of
standardized fine-grain atomic operations and memory barriers.

C++ is going to provide support for the state-of-the-art multi-threading
techniques. If they standard committee listened to you, well, forget about
it. We would all be back to using assembly language. C++ is going to remove
the need for asm and non-blocking algorithms. Why do you fail to understand
that?

I can finally create a 100% standard version of my AppCore library with C++.
If your input was taken into account, well, I could forget about that.
Please, take a break.

:^/

The answer to your questions above is obvious (it is in a library),
At least someone who can admit the obvious.
but this still does not change the fact that threading for a large
part is a language issue.
It should be a language issue but where are those language elements in
C++0x? You say it is a large part of it. It is fact, you say. Can you
show here just a small part of it? Factually.
You just don't get it. The language and the library ARE very intimate with
each other indeed!

Jun 27 '08 #46

P: n/a
On Apr 24, 7:05*pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-04-24 12:37:40 -0400, Szabolcs Ferenczi
<szabolcs.feren...@gmail.comsaid:
...
I remember having seen a number of arguments that day going that the
library solution is not adequate (with reference to the paper of
Boehm) and that C++0x goes for a language-based approach instead.

That's not correct, as several people have told you.
Several people keep saying that there are language elements for multi-
threading in C++0x but nobody could enumerate any single languge
element so far.

Several people did not reply to my request to point out what are the
language elements for concurrency in the proposed C++0x standard. When
I make a list for them, asking (1) what are the language elements for
starting a thread of compulation, (2) by which language elements
mutual exclusion is specified, (3) what are the language elements for
making the threads synchronised---the answer is silence or ignorance
from several people. (Ok, one of them has admitted that these are at
the library level rather than at the language level.)
C++0x has
low-level language-based requirements and a higher level library that
relies on them.
(Unfortunately, Google could have some problem that day since some
posts have disappeared from the web pages.) Having heard that C++0x
tackles threading at the language level I became quite enthusiastic
but when I checked into the document
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
I had to conclude that C++0x also has a pure library approach as far
as threading is concerned.

You're right that C++0x has a high level library.
I only said library. I would not consider it a high level one. In what
respect would it be higher than say ACE library?

For instance let us see the condition variable. It is an object from a
class both in ACE and in C++0x. In ACE you can associate the
corresponding mutex with the condition variable at instantiation time.
Consequently, later on you can just put:

cv.wait();

In C++0x you always have to be at the low level and specify the mutex
again and again which is not only at a low level but it is error prone
too:

cv.wait(lck);

From this respect I would not consider a condition variable in C++0x
being at a high level at all. All I like about it is that there is an
additional method specified which allows you to wait for a predicate
at the higher level indeed:

template <class Predicate>
void wait(unique_lock<mutex>& lock, Predicate pred);

Still, you have to supply the lock.
You're not right that
it's a "pure library approach". The library can't be implemented
correctly without compiler support,
Many libraries are implemented so far correctly (without any compiler
support), as far as I know.

The missing compiler support for algorithms written on top of those
libraries is another question. Still, correct concurrent programs must
be obeyed by the compiler otherwise there is a problem in the
compiler.

By correct concurrent program I mean one where shared variables are
accessed in a mutually exclusive way, as is expected in any correct
concurrent program.

So, what would be really necessary in any decent concurrent language
is to mark the shared variables and then the compiler could check
whether the shared variables are accessed in a mutually exclusive way
or not.
...
Look at the section entitled "Mult-threaded executions and data races".
Thanks for the hint. I had a look at it. Alltogether, that section
considers how the compiler should react to an incorrect concurrent
program. By incorrect concurrent program I mean again as above.

I would not guessed it before that those three pages are the new
language features for concurrency in C++0x.
Without this you cannot write a reliable, portable multi-threaded
application.
Hmmm... How about portable multi-threaded applications written so far?

Best Regards,
Szabolcs
Jun 27 '08 #47

P: n/a
On Apr 25, 2:43 am, "Chris Thomasson" <cris...@comcast.netwrote:
"Szabolcs Ferenczi" <szabolcs.feren...@gmail.comwrote in message
news:68977d32-c840-4029-a3f1->
I really believe
that you should try to read the Böhm paper. If not for your own sake,
then for ours ;-)
Of course I have read it already before I have made my first
contribution to this discussion thread.
Maybe he should have said "understood it", then.

[...]
The whole discussion is built on the assumption: what if
you do not know how to write a correct concurrent program and you use
shared variables without any protection.
Not really. The thrust of Boehm's article is that specifying
when protection is needed, and when it isn't, is a language
issue. Compilers can move code around, and on modern
processors, read and write pipelines also mean that register
loads and stores don't map immediately to memory cycles unless
the compiler generates special instructions around them. The
language has to specify what the compiler is allowed to do, and
what it must do.
I suggest you to study concurrent programming and then
re-read the Boehm paper. You will be surprised.
I suggest you learn about low-level high-performance
multi-threading algorithms. C++ will have efficient support
for them in the form of standardized fine-grain atomic
operations and memory barriers.
Which is a good thing, in itself, but even without such support,
the language still has to address the fundamental issues of
memory synchronization. (Similarly, whether the programmer API
is built into the language, as in Java, or is in the library, as
will be the case in C++, doesn't fundamentally change anything
in this regard.)

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #48

P: n/a
On Apr 25, 10:33 am, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
On Apr 24, 7:05 pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-04-24 12:37:40 -0400, Szabolcs Ferenczi
<szabolcs.feren...@gmail.comsaid:
...
I remember having seen a number of arguments that day going that the
library solution is not adequate (with reference to the paper of
Boehm) and that C++0x goes for a language-based approach instead.
That's not correct, as several people have told you.
Several people keep saying that there are language elements
for multi-threading in C++0x but nobody could enumerate any
single languge element so far.
The Boehm paper explained them in detail. Several people have
suggested that you read it. In the current standard, the basic
execution and memory models start from the point of view that
code is executed sequentially.
Several people did not reply to my request to point out what
are the language elements for concurrency in the proposed
C++0x standard. When I make a list for them, asking (1) what
are the language elements for starting a thread of
compulation, (2) by which language elements mutual exclusion
is specified, (3) what are the language elements for making
the threads synchronised---the answer is silence or ignorance
from several people. (Ok, one of them has admitted that these
are at the library level rather than at the language level.)
No. Several people have pointed out several times where the
language addresses concurrency issues.

[...]
You're not right that it's a "pure library approach". The
library can't be implemented correctly without compiler
support,
Many libraries are implemented so far correctly (without any
compiler support), as far as I know.
The ones I know all depend on compiler support. It's not
defined by the language standard, but it is available as an
extension in many compilers. Not always in compatible manners,
of course.
The missing compiler support for algorithms written on top of
those libraries is another question. Still, correct concurrent
programs must be obeyed by the compiler otherwise there is a
problem in the compiler.
It's still standard conforming.
Without this you cannot write a reliable, portable multi-threaded
application.
Hmmm... How about portable multi-threaded applications written
so far?
Do you know of any? Without some sort of platform dependencies?

--
James Kanze (GABI Software) email:ja*********@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
Jun 27 '08 #49

P: n/a
On 2008-04-25 04:33:22 -0400, Szabolcs Ferenczi
<sz***************@gmail.comsaid:
>
>...
Look at the section entitled "Mult-threaded executions and data races".

Thanks for the hint. I had a look at it. Alltogether, that section
considers how the compiler should react to an incorrect concurrent
program. By incorrect concurrent program I mean again as above.
Not just that. The terms that it defines are used in other places to
specify the meaning of a valid C++ program.
>
I would not guessed it before that those three pages are the new
language features for concurrency in C++0x.
They're the foundation for it.
>
>Without this you cannot write a reliable, portable multi-threaded
application.

Hmmm... How about portable multi-threaded applications written so far?
As you have pointed out, Boehm's article says that library-only
solutions, as used in applications written so far, can't guarantee
semantics. Which is why I referred to "RELIABLE, portable
multi-threaded applications".

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jun 27 '08 #50

126 Replies

This discussion thread is closed

Replies have been disabled for this discussion.