Re: Re: [boost] Re: A new boost::thread implementation?

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-10 12:02:04

> From: "Peter Dimov" <pdimov_at_[hidden]>
> >>     // step 2: execute an async_call
> >>     call();
> >
> > This example, and the implementation above, are just complex
> > synchronous calls.  I assume you really meant for either the
> > constructor or this call to also take an Executor concept?
> 
> This line could be
> 
> boost::thread exec( ref(call) );
> 
> or
> 
> boost::thread_pool pool;
> pool.dispatch( ref(call) );
> 
> I didn't have a prebuilt Boost.Threads library handy when I wrote the code
> (rather quickly) so I used a plain call.

No, it couldn't be, because async_call isn't copyable ;).  But I get the point.
 
> >>     // step 3: obtain result
> >>     try
> >>     {
> >>         std::cout << call.result() << std::endl;
> >>     }
> >>     catch(std::exception const & x)
> >>     {
> >>         std::cout << x.what() << std::endl;
> >>     }
> >> }
> >
> > The one "issue" I see with using operator() to invoke the function is
> > the race conditions that can occur if the user calls this multiple
> > times.  I'd consider it a non-issue personally, since you'd have to
> > go out of your way to use this design incorrectly, but thought I
> > should at least point it out.
> 
> Since operator() is synchronized, i don't see a race... am I missing
> something?

Sort of... I was thinking about the refactoring where you don't hold the mutex the entire time the function is being called.  But even with out the refactoring, there is some room for error:

thread1: call()
thread2: call()
thread1: result() // which result?

But like I said, you have to do some pretty obviously stupid things to get a race here, and I have no intentions of trying to prevent them in our interface.  I just know I'll have to document them.

> > Actually, there's another minor issue as well.  The user can call
> > operator() and then let the async_call go out of scope with out ever
> > calling result().  Mayhem would ensue.  The two options for dealing
> > with this are to either block in the destructor until the call has
> > completed or to simply document this as undefined behavior.
> 
> Yes, good point, I missed that.

I lean towards simple undefined behavior.  How do you feel about it?

William E. Kempf
wekempf_at_[hidden]