Boost logo

Boost :

Subject: Re: [boost] [compute] Some remarks
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-01-02 11:08:56

On Friday, January 02, 2015 00:03:37 Gruenke, Matt wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas
> Heller Sent: Thursday, January 01, 2015 13:56
> To: boost_at_[hidden]
> Subject: [boost] [compute] Some remarks
> > Additionally, I think that the author and other reviewers are running in
> > circles when it comes to synchronization. IMHO, the event alone is enough
> > and perfectly fine.
> It's true that the library could have been designed to rely solely on
> events. All operations could accept wait_lists and return either an event
> or a wait_list (for those algorithms with multiple outputs).
> Since it wasn't done in that way (and I don't mean to imply any judgment,
> here; I recognize there are benefits to the current design), we're in a
> position of looking to plug holes in the existing design to enable full
> exception safety and reduce the set of usage errors that can occur.

Well, that's exactly what I am trying to say ... The current design of the
library completely disregards the research that has been done to support
asynchronous operations. We have std::future (which is almost equivalent to a
OpenCL event), why not use the same mechanisms here? OpenCL event supports
dataflow like statements, which can be expressed with futures just as well.
With the when_XXX and wait_XXX functions as proposed, even wait_list becomes
useless, you'd also gain the ability to mix and match various different
"futures" (by different futures, I mean futures with different shared_state
implementations). This gives you almost perfect composability and exception
safety. This allows to construct algorithms which are tightly coupled, yet are
able to easily overlap different phases of computation. Anything that is
implicitly hidden behind data structures or algorithms seems like a bad idea
to me as you might have to be overly conservative which goes against the
"don't pay for what you don't need" principle.

> 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.
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at