jkelling

> @jkelling Do you have any news related to this bug? No, I did not look into this further.

Not having an "invalid" state is part of the RAII (resource acquisition is initialization) pattern prevalent in alpaka. The "invalid" state after a move is not really such: one should...

> > The "invalid" state after a move is not really such: one should not use an object after it has been moved from, because its state is more undefined...

> Either a type guarantees that an object is _always_ in a valid state, or the user needs to "know" when it is valid or not to use it. That...

> So, to me this boils down to one of > > 1. enforcing that an Event or Queue or Buffer is _always_ valid: either by disallowing moving them (incurs...

In the CI, two checks can be observed to trigger this condition: * queueShouldNotExecuteTasksInParallel * queueCallbackIsWorking

On my local machine, the probability of this occurring is about `0.13 +- 0.04 %`, but judging by #1740 it is significantly higher (~0.9%) in the CI (although, there is...

I would like to clarify (because I always misunderstand when @bernhardmgruber puts it like he did here): The referenced issue affects copy/move *assignment* only, not copy/move in general. I do...

> However, alpaka reference-counted objects can easily work around their `const`-ness, and it's pretty easy to write functions that take `const` arguments and do non-`const` operations: Good point. This is...

The issue is caused by an interaction between the Omp5 and the Omp2Blocks backend with `ALPAKA_OFFLOAD_MAX_BLOCK_SIZE=1`. This leads the Omp5 backend to have a ```c++ #pragma omp parallel num_threads(1) ```...