ownerLockID = 0; // Beware that there might be a very small amount of time where the ownerLockID will be 0, yet locked

Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?
[color=#800000]Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection? [/color]
[color=#BF4000]Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?[/color]
[color=#FFBF00]Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection? [/color]
[color=#FFFF00]Perhaps that can be protected by a CriticalSection?
Perhaps that can be protected by a CriticalSection?[/color]

No, it’s not an issue (and I got the joke). While the criticalSection is locked, the ownerLockID can’t be changed anyway.
The only downside, is if you read the ownerLockID from another thread at the exact moment between ownerID = 0 and lock.trueExit(), then you’ll see 0, but it’s fundamentally safe (any other thread waiting for the CriticalSection will be blocked in enter() so if you break your program at this exact moment, you’d be able to find out which CriticalSection it’s blocked upon, or you can sample your application a ms later and get correct result anyway).

If you need the feature, it’s because you’ve a deadlock, and you want to figure out where it comes from, right ?

Also ownerLockID is an Atomic, so the read in getOwnerThreadId() does actually use the good memory barrier (it’s not reordered by your compiler/CPU).
BTW, if you want a very very fast debugging help, trigger gdb, and print the “CriticalSection”. One of the mutex’s internal field is the count (which should be 0 if free), and another one is the thread owner.