Fiber Aware Mutex

[endevagames]

I've been integrating Jolt into a custom engine and I came across an issue with fiber based job systems.

PhysicsSystem::Update acquires mutexes internally (i.e. the broad phase SharedMutex via MutexArray). If the job system suspends a fiber while it holds one of these locks and later resumes it on a different thread, the unlock happens on a thread that didn't acquire the lock. Which is UB that can cause deadlocking. I'm pretty sure there's a debug assert for this in the repo.

There's two solutions:

1. Just follow how JobSystemWithBarrier works. You end up holding the thread for the duration of the jolt physics step while you wait for other threads to finish working. Not ideal for fiber based job systems as we can't park the fiber and let the thread work on other jobs
2. Allow users to define their own implementations of Mutex and SharedMutex that resolve at link time.

I've done both on my own vendored repo but I was wondering if there was any appetite for this in the main repo. Jolt already has precedent for engine-injectable primitives (JPH::Allocate/JPH::Free) so something similar could be possible.

[jrouwe]

You can already override the mutex by defining JPH_PLATFORM_BLUE, this will require you to implement a few other functions too but it's pretty trivial. Note that if profiling is enabled then it will check if the lock/unlock happens on the same thread.

I'd prefer not to add yet another layer of overridability on top of this.

[endevagames]

Yeah that makes sense. Thanks for the note about behaviour when profiling is enabled!