Hey list, These are just a few remarks I wanted to share that I made during the compute review phase. Unfortunately, I don't have the time to write a full review. As I mostly skimmed over everything so take it with a grain of salt. First of all, I really like the general idea of Boost.Compute. That is, I like the idea of having a proper API for OpenCL capable devices and I like the idea of having parallel algorithms. With that being said, i think it is a waste of opportunities to have the two tied together so closely especially considering N4104 with the combination of different execution policies which would allow for a wonderful API for using different parallelization backends (where boost.compute could be the reference implementation or some such). 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. An OpenCL event has interesting similarities to std::future<void>, and the clEnqueue functions to std::async. I'd consider the command queue however similar to std::thread (and threads should be considered harmful...). With that being said, a event should be perfectly fine to express synchronization points. Together with executors, it would even fit into the more higher level stdlib parallel algorithms. It would be very nice to get rid of a publicly exposed event class though and have one future to rule them all (one can dream...). But having a future and event in Boost.compute is, IMHO, not a good idea. Cheers, Thomas