Boost logo

Boost :

Subject: Re: [boost] [compute] review
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-31 14:41:13


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

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.


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