Re: [Boost-Users] boost::thread not started

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-03-10 13:44:21

justin_michel said:
> Platform : Windows XP, Pentium 4, Visual C++ 6 sp5
>
> I've traced down my problem with starting a thread from a DLL called
> from Java JNI. If you look at the source code thread.cpp in boost,  you
> can see that a condition variable is used block the creating
> thread until the new thread function is started. Basically, what I  am
> seeing is that if you wait on this condition variable, then the  thread
> will never start. If I remove the call to param.wait() at the  bottom of
> the constructor then everything works fine. I can't think  of a logical
> explanation, but it's very repeatable. I was also able  to recreate this
> problem using the latest source from CVS.

I can't explain this.  This has never been reported, and is not an issue
with any of the tests or examples shipped with Boost.Threads.  Can you
create a simple example that reproduces this?

> The simple solution would be to remove the condition variable from
> thread_param code entirely. This would simplify everything, and I  don't
> really see the value anyway. All that is currently guaranteed  is that
> thread_proxy will be called before the boost::thread()
> constructor is finished. But it doesn't guarantee that threadfunc()
> will be called before the constructor is finished.

It gaurantees that the function object is copied before the constructor
finishes.  With out this you have a race condition in which the user
supplied function object may no longer exist by the time the thread goes
to use it.  Removing this wait is not an option.  The only option
available to you beyond using the wait is to dynamically allocate the
proxie's parameter object, copying the user's function object at that
time.  This would require a fair amount of code changes, however, not just
simply commenting out the wait.  And *if* the wait is truly failing, then
you have more issues than this approach will solve any way.  So, let's fix
the actual problem here, if we can determine what it is with a
reproducable example.

-- 
William E. Kempf