multithreading.

[mohi]

hello evreyone ,
when i last posted to ask you people to suggest me where to begin from
for multithreading in c++
a lot many good people suggested me to begin with a good book .
the only one of those many reply had boost library mentioned which i
have heard about before
so can anyone please suggest me a link where i can get good detailed
tutorial meant for a beginner or if u think other things are better to
start with (please also give the links to tutorials if possible ).
thank you
mohan

 

[Ian Collins]

hello evreyone ,
when i last posted to ask you people to suggest me where to begin from
for multithreading in c++
a lot many good people suggested me to begin with a good book .
the only one of those many reply had boost library mentioned which i
have heard about before
so can anyone please suggest me a link where i can get good detailed
tutorial meant for a beginner or if u think other things are better to
start with (please also give the links to tutorials if possible ).

See the current thread with the same heading as yours.

 

[Juha Nieminen]

the only one of those many reply had boost library mentioned which i
have heard about before

You won't even consider OpenMP? It's a much simpler way to use
multithreading in your C++ program. (Of course it requires compiler
support.)

 

[gpderetta]

You won't even consider OpenMP? It's a much simpler way to use
multithreading in your C++ program. (Of course it requires compiler
support.)

Other forms of threading like posix threads and win32 threads also
require compiler support (even if much less extensive).

IIRC, recent releases of Microsoft, Intel and GCC compilers, all
support OpenMP.

 

[Alexander Dong Back Kim]

You won't even consider OpenMP? It's a much simpler way to use
multithreading in your C++ program. (Of course it requires compiler
support.)

Hi Juha,

Could you please give me some hints about benefits and drawbacks of
OpenMP and Boost?

Thanks a lot,
Alex

 

[Alexander Dong Back Kim]

hello evreyone ,
when i last posted to ask you people to suggest me where to begin from
for multithreading in c++
a lot many good people suggested me to begin with a good book .
the only one of those many reply had boost library mentioned which i
have heard about before
so can anyone please suggest me a link where i can get good detailed
tutorial meant for a beginner or if u think other things are better to
start with (please also give the links to tutorials if possible ).
thank you
mohan

Hi Mohan,

If you go the offical boost web site, there is a well organised
documentation stuff. Although it seems it's not perfectly completed,
it's good enough to learn how you can use the library I think =)

Cheers,
Alex D. B. Kim

 

[James Kanze]

You won't even consider OpenMP? It's a much simpler way to
use multithreading in your C++ program. (Of course it
requires compiler support.)

[/QUOTE]

Could you please give me some hints about benefits and
drawbacks of OpenMP and Boost?

They are designed to do completely different things. OpenMP, if
I understand it correctly, is designed largely to parallelize
operations on large arrays, in the presense of multiple cores.
Boost is designed for the classical "threading" applications,
where different threads are used to react to different events,
i.e. one thread can go off and perhaps execute some blocking
requests in response to one event, and the other threads will
continue handling other events.

Boost threads is a very low level wrapper around the system
threads, based more or less on the Posix model (mutexes and
conditions). AS such, I'd strongly recommend it, in
collaboration with the Butenhof (got it right this time, I
hope), for learning the low level basics. In any real
application, of course, you'll probably want to wrap it in
something a bit higher level. (Generally speaking, you'll want
a function to start detached threads, and a thread object with
more or less entity semantics for joinable threads. You can
also consider something like futures.)

 

[Juha Nieminen]

Could you please give me some hints about benefits and drawbacks of
OpenMP and Boost?

One advantage of OpenMP is that, if used properly, the program will
still compile just fine even with compilers with no OpenMP support, and
will work correctly (although only with a single thread).

 

[Jon Harrop]

hello evreyone ,
when i last posted to ask you people to suggest me where to begin from
for multithreading in c++
a lot many good people suggested me to begin with a good book .
the only one of those many reply had boost library mentioned which i
have heard about before
so can anyone please suggest me a link where i can get good detailed
tutorial meant for a beginner or if u think other things are better to
start with (please also give the links to tutorials if possible ).

You should really look at a language with a concurrent garbage collector if
you want to do multithreading. C++ really falls down here because it lacks
a good foundation.

 

[Chris Thomasson]

You should really look at a language with a concurrent garbage collector
if
you want to do multithreading. C++ really falls down here because it lacks
a good foundation.

Why do you think one needs a garbage collector in order to implement
multi-threaded algorithms?

 

[Alexander Dong Back Kim]

They are designed to do completely different things.  OpenMP, if
I understand it correctly, is designed largely to parallelize
operations on large arrays, in the presense of multiple cores.
Boost is designed for the classical "threading" applications,
where different threads are used to react to different events,
i.e. one thread can go off and perhaps execute some blocking
requests in response to one event, and the other threads will
continue handling other events.

Boost threads is a very low level wrapper around the system
threads, based more or less on the Posix model (mutexes and
conditions).  AS such, I'd strongly recommend it, in
collaboration with the Butenhof (got it right this time, I
hope), for learning the low level basics.  In any real
application, of course, you'll probably want to wrap it in
something a bit higher level.  (Generally speaking, you'll want
a function to start detached threads, and a thread object with
more or less entity semantics for joinable threads.  You can
also consider something like futures.)

--
James Kanze (GABI Software)             email:[email protected]
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

Thank you very much! What an impressive reply was that!!!
I compliment on your deep knowledge =)

 

[Alexander Dong Back Kim]

Why do you think one needs a garbage collector in order to implement
multi-threaded algorithms?

same question here =)

 

[Jon Harrop]

Why do you think one needs a garbage collector in order to implement
multi-threaded algorithms?

Unless your allocation lifetimes happen to be statically well defined,
you'll essentially end up reinventing a garbage collector. That is hard
enough in single threaded applications but it is much harder in the
presence of multithreading because it is so error prone.

 

[Chris Thomasson]

[comp.programming.threads added]

Unless your allocation lifetimes happen to be statically well defined,
you'll essentially end up reinventing a garbage collector. That is hard
enough in single threaded applications but it is much harder in the
presence of multithreading because it is so error prone.

That does not make sense. I choose the right lifetime management scheme
for the algorithms I need to implement. To this date, I have not
"needed" full-blown garbage collection. I mainly make use of distributed
reference counting and proxy collectors to manage the memory in
non-blocking algorithms. This is not reinventing a garbage collector at
all. BTW, garbage collectors have their share of problems; here are some
of them:


http://groups.google.com/group/comp.programming.threads/browse_frm/thread/5e9357a6fb746e5d

 

[James Kanze]

mohi wrote:

You should really look at a language with a concurrent garbage
collector if you want to do multithreading. C++ really falls
down here because it lacks a good foundation.

The issues seem orthogonal to me, but FWIW: there are efficient
garbage collectors available for C++. I know. I use them.

 

[James Kanze]

That does not make sense. I choose the right lifetime
management scheme for the algorithms I need to implement.

Object lifetime and garbage collection are orthogonal---garbage
collectors do NOT manage object lifetime. And of course, both
are orthogonal to threading---except that like just about
everything else, it's harder to implement the algorithms used
(garbage collector, or the alternatives) in the presence of
threads.

To this date, I have not "needed" full-blown garbage
collection.

You never "need" it. (For that matter, you never need C++, or
even C. You can do everything in assembler.)

I mainly make use of distributed reference counting and proxy
collectors to manage the memory in non-blocking algorithms.
This is not reinventing a garbage collector at all. BTW,
garbage collectors have their share of problems; here are some
of them:

http://groups.google.com/group/comp.programming.threads/browse_frm/th...

Nothing is perfect, and there are contexts where garbage
collection may not be the answer. Or garbage collection mixed
with something else. It's a nice option to have, and makes
coding a few specific things easier, but it's not a silver
bullet.

 

[Jon Harrop]

...efficient garbage collectors available for C++. I know. I use them.

I do not believe that is true. Have you benchmarked them?

 

[Jon Harrop]

That does not make sense. I choose the right lifetime management scheme
for the algorithms I need to implement. To this date, I have not
"needed" full-blown garbage collection. I mainly make use of distributed
reference counting and proxy collectors to manage the memory in
non-blocking algorithms. This is not reinventing a garbage collector at
all.

Reference counting was one of the earliest forms of garbage collection and
it is riddled with many very serious and well known problems. You are
literally reinventing the GC and you are now several decades out of date.

BTW, garbage collectors have their share of problems; here are some
of them:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/5e9357a6fb746e5d

The thread you cite is a discussion about two different articles, neither of
which substantiate your claim:

The first is an article describing problems with a specific Java data
structure (WeakHashMap):

http://blogs.azulsystems.com/cliff/2007/08/why-weakhashmap.html

As the commenters on that post have already explained in detail, the
author's use of this data structure is wrong and many of his statements
about it are wrong because he didn't bother to read the documentation. For
example, read the comment:

"I'm hoping the irony in the title is intentional. There are several
layers of "suck" going on here and WeakHashMap is the least of them.
Assuming you have a correct hashcode and concurrent GC, as you said
everything gets cleared out really fast and the Javadocs explain all this."

i.e. the poster's problem is a direct result of the GC being too efficient
at collecting unused values. This problem is commonly cited in many GC'd
languages by newbies who are trying to abuse the garbage collector.

The second article describes a problem with memory fragmentation:

http://www.coversant.net/Coversant/Blogs/tabid/88/EntryID/9/Default.aspx

As the poster described, this problem is entirely a result of pinning, i.e.
manual memory management. As he explains, if the code were entirely
high-level with automatic memory management this problem would never have
occurred because the (moving) GC automatically defragments the heap.

 

[Chris Thomasson]

Reference counting was one of the earliest forms of garbage collection and
it is riddled with many very serious and well known problems.

cycles aside, can you list several other very serious problems? BTW, IMHO,
cycles are a red-herring and can usually be designed around.

You are
literally reinventing the GC and you are now several decades out of date.

How are virtually zero-overhead counting algorithms out-of-date? Please
explain...

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/5e9357a6fb746e5d

The thread you cite is a discussion about two different articles, neither
of
which substantiate your claim:

The first is an article describing problems with a specific Java data
structure (WeakHashMap):

[...]

How do you effectively cache object's in a "collect-the-world" environment?
GC and caching don't get along _sometimes_... From the applications point of
view an object in the cache is in a quiescent state. However, from the GC
perspective a node in the cache is a pointer to a "live object".

 

[Chris Thomasson]

Object lifetime and garbage collection are orthogonal---garbage
collectors do NOT manage object lifetime.

They determine when an object is quiescent which is probably the most
important aspect of lifetime management schemes in general.

And of course, both
are orthogonal to threading---except that like just about
everything else, it's harder to implement the algorithms used
(garbage collector, or the alternatives) in the presence of
threads.

You never "need" it. (For that matter, you never need C++, or
even C. You can do everything in assembler.)
Agreed.

Nothing is perfect, and there are contexts where garbage
collection may not be the answer. Or garbage collection mixed
with something else. It's a nice option to have, and makes
coding a few specific things easier, but it's not a silver
bullet.

Agreed.