Re: Basic Question on POSIX Threads
On Oct 16, 8:35 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
On Oct 15, 3:58 pm, "Laurent D.A.M. MENTEN"
You're right about the race condition, of course, and I doubt
that his code would work on a modern system (dual core or more).
But it won't even compile with a conformant C++ compiler. His
function glue must be `extern "C"', and thus cannot be a member.
(On the other hand, it *can* be static, in order to avoid all
risk of name collision.)
Anyway, it does compile (gcc 3.3.5 + linux 2.6.11 + x86_64)
This is a known bug in g++, which will presumably be fixed in a
future release. At which point, your code will stop compiling.
It is a shame so many people here are not able to understand not
everyone in this world is a C++ guru or theorician.
It's a shame so many people don't care about writing correct
Not sure why C++ threading has to be overally complicated... I
mean, why not something simple like:
It's not the threading per se which is complicated, it's the
management of the other associated resources. Both Gianni's
code (if I've understood it correctly) and Boost support the
simple use of detached threads, where the user doesn't have to
worry about the lifetime of the thread object. In other words,
the creator of the thread doesn't have to maintain an object
himself, and delete it when the thread is ended.
IMHO, that's probably overkill (and at least in the case of
Boost, it works against you) if you're joining, and want to
recover work done by the thread. On the other hand, it's very,
very convenient for detached threads---in the implementation you
posted, if you don't join, you leak resources, and if the thread
is of the fire and forget nature, you have to do a lot of extra
work to ensure destructing your thread object correctly when the
thread has terminated.
One of the real problems with threading is that so many people
consider only a single solution, where as it's definitly not a
case of one size fits all. I use a simple thread class, very
similar to the one which started the discussion here (but using
the strategy pattern, of course, and an `extern "C"' function to
start the thread) for joinable threads; my interface for
detached threads is a simple function, much like yours, but I
copy the functional object, and interlock with the new thread
(like Gianni and Boost) for detached threads. And I'm sure I've
not begun to cover all of the various uses.
James Kanze (GABI Software) email:email@example.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34