On Friday, January 02, 2015 00:03:37 Gruenke, Matt wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Heller Sent: Thursday, January 01, 2015 13:56 To: boost@lists.boost.org 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: http://lists.boost.org/mailman/listinfo.cgi/boost