Laurent D.A.M. MENTEN wrote:
>> 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) and it does
> its work pretty well for my own personal needs. I never claimed it was
> complete or portable, nor did I claim it was conformant and I will never
> claim it is the best and only implementation.
>
It's more a case of it being a dangerous solution. There is every
chance the thread will run before the object is constructed on a
multi-core system, or even a single code one if the new thread gets to
run first.

> The point is I answered a simple question with simplicity. My skeleton
> allows Mr. JackC to work with thread and objects in an easy way, further
> more I sticked to the logic I (believe I have) found in the code sample
> in the original post and tried my best to Mr. JackC understand mine.
>
> It is a shame so many people here are not able to understand not
> everyone in this world is a C++ guru or theorician.

There is nothing theoretical about race conditions or incorrect
parameter types.

--
Ian Collins.