Subject: Re: [boost] Futures
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-05 14:10:58
Am 05.01.2015 19:11 schrieb "Gruenke,Matt" <mgruenke_at_[hidden]>:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas
> Sent: January 05, 2015 10:30
> To: boost_at_[hidden]
> Subject: Re: [boost] Futures
> > However, there is one thing that this implementation didn't solve so
> > that's the ability to retrieve the specific type of the shared_state
> > turned into a future. That's needed for an OpenCL backend to use the
> > the enqueueRangeND functions to make them useful in the OpenCL context
> If you're talking about passing a future as a parameter of an operation,
so it can be included as part of a wait_list, then I fully agree. What any
good OpenCL wrapper should support is explicit expression of dependencies
to the OpenCL driver, rather than implicitly enforcing data dependencies
through host-based synchronization.
Yes and no ;) the idea is to construct the wait list behind the scenes in
the opencl wrapper to avoid host based synchronization of the opencl event.
On the other end however, the unified interface would allow to additionally
synchronize on other future types, for example data coming over a network.
This would be an extremely powerful tool to have available. I believe we
have a nice and efficient proof of concept already available in HPX.
Unfortunately, the pushed opencl wrapper (hpxcl) doesn't fully use the
uniform future based interface yet (we are currently ironing out the last
conceptual problems to also support remote opencl devices), but the essence
is already there.
> Even if this is only possible by deriving from a standard future type, of
some sort, I think that would still be preferable to introducing its own
completely custom type.
> This e-mail contains privileged and confidential information intended for
the use of the addressees named above. If you are not the intended
recipient of this e-mail, you are hereby notified that you must not
disseminate, copy or take any action in respect of any information
contained in it. If you have received this e-mail in error, please notify
the sender immediately by e-mail and immediately destroy this e-mail and
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk