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)
>>> 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
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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk