Cuda UniqueToken interface not consistent with other backends

[ibaned]

@etphipp wrote:

All of the other implementations of UniqueToken<> have a default constructor of the form

UniqueToken( execution_space const& = execution_space() )

except the Cuda one. Is there a reason the Cuda one has a separate default constructor without an execution space argument (resulting in a UniqueToken that is basically useless)?

Btw, the Cuda specialization is missing the definition of size_type to be consistent with all of the others, e.g.,

using size_type       = int32_t;

[mhoemmen]

@tjfulle may be interested in this.

[ndellingwood]

It looks like concurrency() is to be deprecated in favor of UniqueToken, consistent default constructors will help with consistency and avoiding if-guards based on enabled backends when replacing concurrency() within Kokkos (and other codes).

[ibaned]

Actually, I just talked to @dsunder . concurrency should not have been deprecated, that was a mistake. I'm about to open a pull request that does the deprecation correctly for all common back-ends.

[william76]

@ibaned
I'm trying to use UniqueToken on a PR in Kokkos-Kernels 299 but it's not working... I've looked at examples showing how UniqueToken needs to be called differently for CUDA than the others?

I've looked at #1499 (comment) but I've tried using a c'tor with my execution space as the parameter and fails to compile on Cuda.

[william76]

Ahhh, I got it working. Using unique_token_t( ExecutionSpace() )