Add a simple spinlock mutex type

[stephenswat]

In order to facilitate some edge case handling in device code, this commit adds a very simple spinlock-type mutex using vecmem atomic references.

[stephenswat]

This will fail until acts-project/vecmem#275 is merged.

[stephenswat]

This is now ready for review.

[krasznaa]

Is the templating actually needed? Could we not just choose one specific integer type that would need to be used with mutexes? This way we just make it easier for somebody to use an inappropriate type. 🤔 (With a bunch of complicated compiler errors to follow.)

Of course in that case the functions will all need to be explicitly declared inline. (They are currently implicitly that because of the templating.)

[krasznaa]

Also-also: Would it not be good to also provide a traccc::device::lock_guard type? Since it's usually not a good idea to call lock() and unlock() on a mutex manually. 🤔

Unfortunately I don't think that we could use std::lock_guard with CUDA. (I'm pretty sure that SYCL would accept it though.) Since that would be the nicest, using our custom mutex with the general lock guard...

[stephenswat]

Unfortunately, it's not that simple. 😟 Because RAII is implicitly executed by every thread in a warp, using a naive lock_guard structure would guarantee deadlock as 32 threads simultaneously try to lock the same mutex. The way out of this would be to implement lock_guard-like types for every platform, but then we start hiding which thread owns the lock from the user, which is in itself bad if they want to do sub-group level work division... The only way I can image that would make this work is to incorporate cooperative groups into the mix, but we don't use those anywhere, and while SYCL has an equivalent semantic construct I am not sure if HIP, Alpaka and Kokkos do.

[stephenswat]

Is the templating actually needed? Could we not just choose one specific integer type that would need to be used with mutexes?

The danger here is that different platform might support lock-free operations on different types. And some types may be slower than others. Although I am pretty sure something like uint32_t is a sane choice on most platforms, I think it makes sense to leave the choice open to the user. A good default value is probably a nice idea, though.

[krasznaa]

Any chance of adding some SYCL tests as well...? Read: Please add SYCL tests as well.

[stephenswat]

Sure, I can add some SYCL tests. But this kind of "write one piece of common code, have to write tests for all platforms" is going to quickly become unmanageable if we start doing the same for Kokkos, Alpaka, etc. 😟

[krasznaa]

I'm very open to suggestions. But we must test it somehow that the "common code" indeed works correctly on all backends that we want to use. If you prefer to set up just one test with Alpaka or Kokkos for all available backends, I'm fine with that.

[stephenswat]

This is now ready, with SYCL tests.

[krasznaa]

The lock <-> _lock names are used in a bit confusing way in the SYCL tests, but since those are just tests, this is more of a nitpick. Other than that, this seems fine.