class Sync

Ensure that previous messages, including Duplicate() messages on a

token, collection, or group, have been received server side.

Calling BufferCollectionToken.Sync() on a token that isn't/wasn't a

valid sysmem token risks the Sync() hanging forever. See

ValidateBufferCollectionToken() for one way to mitigate the possibility

of a hostile/fake BufferCollectionToken at the cost of one round trip.

Another way is to pass the token to BindSharedCollection(), which also

validates the token as part of exchanging it for a BufferCollection

channel, and BufferCollection Sync() can then be used.

After a Sync(), it's then safe to send the client end of token_request

to another participant knowing the server will recognize the token when

it's sent into BindSharedCollection() by the other participant.

Other options include waiting for each token.Duplicate() to complete

individually (using separate call to token.Sync() after each), or

calling Sync() on BufferCollection after the token has been turned in

via BindSharedCollection().

Another way to mitigate is to avoid calling Sync() on the token, and

instead later deal with potential failure of BufferCollection.Sync() if

the original token was invalid. This option can be preferable from a

performance point of view, but requires client code to delay sending

tokens duplicated from this token until after client code has converted

the duplicating token to a BufferCollection and received successful

response from BufferCollection.Sync().

Prefer using BufferCollection.Sync() instead, when feasible (see above).

When BufferCollection.Sync() isn't feasible, the caller must already

know that this token is/was valid, or BufferCollectionToken.Sync() may

hang forever. See ValidateBufferCollectionToken() to check token

validity first if the token isn't already known to be (is/was) valid.