Re: [boost] Futures

Subject: Re: [boost] Futures
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2015-01-05 13:11:29

-----Original Message-----
From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas Heller
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 far and
> that's the ability to retrieve the specific type of the shared_state once it's
> turned into a future. That's needed for an OpenCL backend to use the OpenCL in
> the enqueueRangeND functions to make them useful in the OpenCL context again ...

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.

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.


Matt


________________________________

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 its attachments.