Subject: Re: [boost] Synchronization (RE: [compute] review)
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2014-12-28 22:43:26
On 2014-12-28 20:35, Kyle Lutz wrote:
> On Sun, Dec 28, 2014 at 4:46 PM, Gruenke,Matt <mgruenke_at_[hidden]> wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
>> Sent: Sunday, December 28, 2014 14:42
>> To: boost_at_[hidden] List
>> Subject: Re: [boost] [compute] review
>>
>>> On Sun, Dec 28, 2014 at 1:54 AM, Gruenke,Matt wrote:
>>>> Also, I agree with Thomas M that it'd be useful for operations to return events.
>>
>>> All asynchronous operations in the command queue class do return events. One of his
>>> comments was to also return events from the synchronous methods for consistency and
>>> I am working on adding this.
>>
>> Well, what I had in mind was events for higher-order operations, like boost::compute::transform().
>
> Yes, I would also like to have higher-level support for chaining
> together algorithms asynchronously. However, designing a generic and
> generally useful API for this is a complex task and may take some time
> and (I've shied away from just adding an extra "_async()" function for
> all of the algorithm APIs as I think it could be done
> better/more-extensibly). Any ideas/proposals for this would be great
> to hear.
The approach that people seem to be converging on is using futures and
continuations for this sort of thing. I think that works here.
See for example HPX <https://github.com/STEllAR-GROUP/hpx>
Given that you already have a wait_list object, I imagine that the
required primitives are already there in OpenCL to chain operations in
arbitrary graphs.
John Bytheway