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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-12 13:26:52

Peter Dimov said:
> William E. Kempf wrote:
>>>>     R result() const
>>>>     {
>>>>         boost::mutex::scoped_lock lock(m_mutex);
>>>>         while (!m_result)
>>>>             m_cond.wait(lock);
>>>
>>> This changes result()'s semantics to "block until op() finishes";
>>> what happens if nobody calls op()? Or it throws an exception?
>>
>> Changes the semantics?  I thought this was what was expected and
>> illustrated in every example thus far?
>
> No, my example throws an exception when the call hadn't been made. It
> would also throw when the call has been made but did not complete due to
> an exception, had I added a try block in operator() that eats the
> exception.

Would work, but can complicate (not prevent) usage patterns where the
future<> is shared across threads.  However, see below.

>>>>     future(const future<R>& other)
>>>>     {
>>>>         mutex::scoped_lock lock(m_mutex);
>>>
>>> I don't think you need a lock here, but I may be missing something.
>>
>> I have to double check the implementation of shared_ptr<>, but I was
>> assuming all it did was to synchronize the ref count manipulation.
>> Reads/writes of the data pointed at needed to be synchronized
>> externally.
>
> Yes, you are right. The lock is necessary to achieve the level of thread
> safety that you implemented. I think that a "thread neutral" (as safe as
> an int) future<> would be acceptable, since this is the thread safety
> level I expect from lightweight CopyConstructible components, but that's
> not a big deal.

I was focusing on making the type sharable across threads in a thread safe
manner.  However, stepping back and thinking on it, I think that may have
been the wrong approach.  Most usage patterns won't involve this sharing,
so paying the cost for synchronization regardless is probably not a good
idea.  I think it would be better to take the "thread neutral" approach. 
Thanks for getting me to think about this issue.

-- 
William E. Kempf