Boost logo

Boost :

Subject: Re: [boost] [compute] review
From: Thomas M (firespot71_at_[hidden])
Date: 2014-12-31 16:18:30


On 31/12/2014 20:41, Gruenke,Matt wrote:
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Kyle Lutz
> Sent: December 30, 2014 14:09
> To: boost_at_[hidden] List
> Subject: Re: [boost] [compute] review
>
>> On Tue, Dec 30, 2014 at 7:15 AM, Vicente J. Botet Escriba wrote:
>
>>> I would prefer that the algorithms take as first parameter the queue
>>> (which could be abstracted to an asynchronous executor).
>>
>> Any particular reason to prefer the first argument rather than the last?
>> Currently, by using the last argument to specify the command queue, we
>> can use a default argument of "system::default_queue()". For the common
>> case of only wanting to use the default compute device on the system, all
>> algorithms will work correctly and the user never has to bother with
>> finding a device, setting up a context, creating a command queue and
>> passing it to the algorithm function.
>
> While that's certainly convenient, it does open the door to a subtle (but serious) error. In code not using the default queue, one or more of the functions may inadvertently omit that parameter. This would result in operations being directed to different queues, introducing race conditions.
>
> I would not give the queue parameter a default. It's not hard for them to explicitly call system::default_queue(), at the top of their code, save the result, and pass it into their functions. They still wouldn't need to find devices, setup contexts, etc.

I fully second that; I also see little gained by the default parameter
but quite some (unnecessary) risks introduced.

Thomas


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk