RE: [boost] Re: Re: Threads & Exceptions

From: Yitzhak Sapir (yitzhaks_at_[hidden])
Date: 2002-08-07 06:00:05

> -----Original Message-----
> From: Pete Becker [mailto:petebecker_at_[hidden]]

> At 07:35 PM 8/6/2002 +0200, Yitzhak Sapir wrote:
> >To solve this, the destructor of the most inherited class 
> has to call 
> >join().  This means you're assuming the user of oo_thread 
> calls join() in 
> >the most inherited thread
> 
> No, I'm not making any such assumption.
> 
> >
> >It causes access violations in the run() function.
> 
> Only if you allow it to continue running.
> 

I originally pointed out a bug in Peter Dimov's suggestion for oo_thread.  Peter seems to have agreed with me.  You then said "that is easily detected in the base class."  I assume therefore that you take responsibility for the correctness or usefulness of his implementation of oo_thread.  If not, I expect to see your idea of implementation of oo_thread, so the discussion can have some specific code to reference.  Maybe it will employ some technique I haven't thought of, and solve all these problems.  In any case, the current oo_thread prevents you from calling join() in your inherited class destructor, thus, forcing you to a race condition.

Overall, I provided detailed explanation of the problems in thread wrapper classes and why they don't give you real advantage in the end.  You responded with one line unsubstantiated statements:

That is easily detected in the base class.  (How do you detect it?  By the time you detect it, can you do anything useful about the issue to prevent any fatal or bad side effects?)
I'm not making any such assumption.  (So how would you solve the basic problem without making this assumption -- that the user calls join() in the most inherited class?)
Only if you allow it to continue running.  (How would you prevent it from running?  Remember not to make the assumption that the user calls join() in the most inherited class.)

So, please substantiate... :-)

> >  and calls start() in the most inherited thread.  You have 
> no way of 
> > forcing him to do so or making sure he does so.
> 
> Nor do I want to. It's up to the user to use the class correctly.

Could you please provide a correct use example of the oo_thread class that does not get into race conditions? (I don't believe anyone could, because I believe there is no "correct use" of that code because of that bug, but you seem to think it's an issue best left to the user).

I should point out that this race condition is the type of bug that might happen only in release mode only every so often (where the truth is that it is vulnerable in debug mode too, but timing differences make it much less likely).  It is very annoying to find, and debug, and therefore best to do it correctly to start with.  IMO, Boost.Threads' model makes it easy, by making it easy to do it the correct way, and making it harder to do it the wrong way.