From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-06-01 18:53:28
On Friday 30 May 2008 18:10, Johan Torp wrote:
> Frank Mori Hess wrote:
> > once all the input futures are ready. I see 3 options:
> > 1) The combiner is run in a future-waiting thread.
> > 2) The combiner is run in a promise-fulfilling thread.
> > 3) The combiner is run in its own thread.
> I really hope option 1 is implementable without holding any locks. Could
> explain in more detail what problems you ran into?
I've got it working locally now. The combiner and any implicit
type-conversions now only happen in future-waiting threads, and they are
run without holding locks. I haven't committed it yet though, since it
breaks my scheduler (due to some futures not completing until a wait or a
future::ready/has_exception query is performed). This makes my scheduler
stall, so I'll need to implement a reasonably efficient re-useable "wait
for any" like future_selector to fix it. The changes also add some
overhead. I haven't done any measurements, but the amount of
locking/unlocking of mutexes has definitely increased.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk