Should we provide additional debug information for frequent threading issues

[miscco]

One of the most common reasons for deadlocks is the same thread trying to lock an already hold mutex or aquiring an already held semaphore

We could improve user experience, by storing the thread.id of the locking thread in the mutex/semaphore and compare it the previously stored one.

This would obviously be an ABI break as we would increase the size of atomic_semaphore_base but would eliminate one of the most common pitfalls in multithreaded applications.

This came up during a discussion with @gonzalobg of the new mutex implementation

[miscco]

I want to stress that while I personally see a clear benefit to that strategy I am exceptionally wary of changing the size of a data structure depending on DEBUG / RELEASE builds

That can have completely unexpected consequences for code that has well tuned data layouts

[gonzalobg]

I agree with the concerns about changing the size of the data-structure, but it might be the practical thing to do.

We do have alternatives, like picking different mutex implementations in which the debug state would not impact the size of the std::mutex.

[miscco]

I mean for mutex and binary_semaphore it is easily possible because we could "borrow" 63 bits from the internal counter and extract those when needed.

That said it would require us specializing those data structures which is a considerable maintenance burden

[gonzalobg]

For mutex my preference would be to have a lock-table, such that mutex becomes a "pointer" or "key" to index the table. In the table, we can have as much state as we want, and we can change the state, without impacting the "size" of the mutex (but it would still impact the ABI).

[miscco]

I mean there is no mutex yet so ABI is still on the table. It is just that we couldnt simply reuse semaphore directly.

Also it would greatly complicate heterogeneous usage between host and device