Upon further consideration... -----Original Message----- From: Gruenke,Matt Sent: Tuesday, December 30, 2014 8:49 To: boost@lists.boost.org Subject: RE: [boost] Synchronization (RE: [compute] review)
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas M Sent: Tuesday, December 30, 2014 7:37 To: boost@lists.boost.org Subject: Re: [boost] Synchronization (RE: [compute] review)
c) a guard for a command-queue as whole [possibly guards for other classes as well]
Why? Convenience?
Unless you're using it as a shorthand for waiting on individual events or wait_lists, there's no need. The event_queue is internally refcounted. When the refcount goes to zero, the destructor will block on all outstanding commands.
I should've listed to myself more carefully. I think this means command_queue-level guarantees aren't necessary or useful, because you've either got: 1) A local command_queue, with a refcount of 1, in which case it will block upon destruction. 2) A copy of a nonlocal command_queue, in which case there may be unrelated commands in the queue. It's up to Kyle if he wants it, but I'd skip the command_queue::guarantee, as it would likely lead to confusion, misuse, and generally sloppy code. 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.