Re: [boost] Synchronization (RE: [compute] review)

Subject: Re: [boost] Synchronization (RE: [compute] review)
From: Gruenke,Matt (mgruenke_at_[hidden])
Date: 2014-12-30 09:01:52

Upon further consideration...

-----Original Message-----
From: Gruenke,Matt
Sent: Tuesday, December 30, 2014 8:49
To: boost_at_[hidden]
Subject: RE: [boost] Synchronization (RE: [compute] review)

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas M
> Sent: Tuesday, December 30, 2014 7:37
> To: boost_at_[hidden]
> 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.