C++ standards for thread management

Morpheus wrote:

Hi,

I have been coding in Windows for many years so have a mindset to it,
so forgive any stupid questions.

Is it possible to create a multithread application in C++ that is
portable (OS/compiler)? In my Windows applications, I use
synchronization objects like, mutex, semaphores etc. Is there anything
similar in the Standard ANSI C++ or would I be best off doing this
myself, possibly creating a new class to handle any critical sections
and memory sharing etc.

Any articles on this subject are welcome as well.

There is no support for threads or the kind of synchronisation objects
you mention in standard C++. However, before you write everything you
need from scratch, you might want to have a look at the threads library
in boost.

http://www.boost.org/doc/html/threads.html

See if it does what you want and if it is portable to the platforms you
care about.

Gavin Deane

Morpheus wrote:

Is it possible to create a multithread application in C++ that is
portable (OS/compiler)? In my Windows applications, I use
synchronization objects like, mutex, semaphores etc. Is there anything
similar in the Standard ANSI C++ or would I be best off doing this
myself, possibly creating a new class to handle any critical sections
and memory sharing etc.

Any articles on this subject are welcome as well.

Check out this article on Boost.Threads:

http://www.ddj.com/dept/cpp/184401518

And you might be interested in this article on the future of threads in
standard C++:

http://www.artima.com/cppsource/threads_meeting.html

Cheers! --M

"Morpheus" <ad***********@ gmail.comwrote in message
news:11******** *************@h 48g2000cwc.goog legroups.com...

Hi,

I have been coding in Windows for many years so have a mindset to it,
so forgive any stupid questions.

Is it possible to create a multithread application in C++ that is
portable (OS/compiler)? In my Windows applications, I use
synchronization objects like, mutex, semaphores etc. Is there anything
similar in the Standard ANSI C++ or would I be best off doing this
myself, possibly creating a new class to handle any critical sections
and memory sharing etc.

Any articles on this subject are welcome as well.

Here are some link to some relevant information:

http://groups.google.com/group/comp....d30a778b43f2c5
http://groups.google.com/group/comp....f096adecdd0369
(refer to last part of the post...)
http://groups-beta.google.com/group/...3df394a0370fa6

FWIW, I raise this issue in a very rough draft of a paper I am currently
working on. Here is a link to the crude draft:

http://appcore.home.comcast.net/vzdo...c/static-init/

Its incomplete, however, what's there should be of interest to you...
Any thoughts?

Morpheus wrote:

>
Is it possible to create a multithread application in C++ that is
portable (OS/compiler)? In my Windows applications, I use
synchronization objects like, mutex, semaphores etc. Is there anything
similar in the Standard ANSI C++ or would I be best off doing this
myself, possibly creating a new class to handle any critical sections
and memory sharing etc.

Any articles on this subject are welcome as well.

Thread-related proposals under discussion for the next C++ standard:

Concurrency memory model
http://www.open-std.org/jtc1/sc22/wg...2006/n2052.htm

Thread-local storage
http://www.open-std.org/jtc1/sc22/wg...006/n1966.html

Atomic operations
http://www.open-std.org/jtc1/sc22/wg...006/n2047.html

Thread support
http://www.open-std.org/jtc1/sc22/wg...005/n1907.html
http://www.open-std.org/jtc1/sc22/wg...006/n2090.html
--

-- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

"Gavin Deane" <de*********@ho tmail.comwrote in message
news:11******** **************@ m73g2000cwd.goo glegroups.com.. .

Morpheus wrote:

>Hi,

I have been coding in Windows for many years so have a mindset to it,
so forgive any stupid questions.

Is it possible to create a multithread application in C++ that is
portable (OS/compiler)? In my Windows applications, I use
synchronizatio n objects like, mutex, semaphores etc. Is there anything
similar in the Standard ANSI C++ or would I be best off doing this
myself, possibly creating a new class to handle any critical sections
and memory sharing etc.

Any articles on this subject are welcome as well.

There is no support for threads or the kind of synchronisation objects
you mention in standard C++. However, before you write everything you
need from scratch, you might want to have a look at the threads library
in boost.

http://www.boost.org/doc/html/threads.html

See if it does what you want and if it is portable to the platforms you
care about.

Right. You can also get a commercial version of boost threads, already
ported to several major platforms, from us. But you might want to
check out Boost first. We also have documentation in the on-line manual
at our web site, for a quick overview.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Pete Becker wrote:

Morpheus wrote:

>>
Is it possible to create a multithread application in C++ that is
portable (OS/compiler)? In my Windows applications, I use
synchronizatio n objects like, mutex, semaphores etc. Is there anything
similar in the Standard ANSI C++ or would I be best off doing this
myself, possibly creating a new class to handle any critical sections
and memory sharing etc.

Any articles on this subject are welcome as well.

Thread-related proposals under discussion for the next C++ standard:

Concurrency memory model
http://www.open-std.org/jtc1/sc22/wg...2006/n2052.htm

Thread-local storage
http://www.open-std.org/jtc1/sc22/wg...006/n1966.html

Atomic operations
http://www.open-std.org/jtc1/sc22/wg...006/n2047.html

Thread support
http://www.open-std.org/jtc1/sc22/wg...005/n1907.html
http://www.open-std.org/jtc1/sc22/wg...006/n2090.html

Since it's for the most part language adoption of Posix thread apis which
where established in the 90's, shouldn't it be called C++9x instead of
C++0x?

Seriously, the hardware is advancing at a faster rate than software
support for threading. This stuff won't scale for 100+ core processors.
This doesn't even begin to address the issues faced by techniques being
developed now. This is just language support for the last war so to
speak.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Joe Seigh wrote:

>
Seriously, the hardware is advancing at a faster rate than software
support for threading. This stuff won't scale for 100+ core processors.
This doesn't even begin to address the issues faced by techniques being
developed now. This is just language support for the last war so to
speak.

I don't know how to write code that will scale to 100+ core processors,
much less what standard language support for it ought to look like. But
from the three-day special meeting we had in Redmond last month, which
included representatives from several hardware manufacturers as well as
people with far more experience writing multi-threaded code than I have,
I don't think anyone else does, either.

You're right that the papers pretty much stick to what's in existence
today. That's what language standards ought to do: standardize existing
practice. But note also that those papers are aimed at the next revision
of the C++ standard, which is pretty much feature-frozen now. There's
more going on, but it's targeted farther out in the future, and is still
somewhat speculative.

--

-- Pete
Roundhouse Consulting, Ltd. -- www.versatilecoding.com
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

Pete Becker wrote:

Joe Seigh wrote:

You're right that the papers pretty much stick to what's in existence
today. That's what language standards ought to do: standardize existing
practice. But note also that those papers are aimed at the next revision
of the C++ standard, which is pretty much feature-frozen now. There's
more going on, but it's targeted farther out in the future, and is still
somewhat speculative.

I'm a little concerned since there doesn't seem to be any awareness of
some of the issues I've been running into. Being on the bleeding
edge isn't any fun when they move that edge out from under you and
you do a Wiley Coyote. I've had that happen to me in Java when they
revised the JVM specs and broke something I did that was legal in
Java 1.x. Fortunately I wasn't really using it but nevertheless.
--
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

Joe Seigh wrote:

Pete Becker wrote:

Joe Seigh wrote:

You're right that the papers pretty much stick to what's in existence
today. That's what language standards ought to do: standardize existing
practice. But note also that those papers are aimed at the next revision
of the C++ standard, which is pretty much feature-frozen now. There's
more going on, but it's targeted farther out in the future, and is still
somewhat speculative.

I'm a little concerned since there doesn't seem to be any awareness of
some of the issues I've been running into. Being on the bleeding
edge isn't any fun when they move that edge out from under you and
you do a Wiley Coyote.

That's the price of living on the bleeding edge. The stuff the standard
is concerned with is, as Pete said (cf. also the article I mentioned
elsethread), not on the bleeding edge precisely because the edge
changes so rapidly. Only common practice should be standardized, not
any of the myriad possible future practices.

Cheers! --M