Oh boy some mutex deadlocks inside the 16 year old, unmaintained, company application framework.

Time to look at the stack traces of 24 different threads and try and guess which one fucks it up

(Send help)

Sounds like a good time. You don't have to look at the backlog for the next few weeks if you play your cards right.

@RemusWasTaken this would imply we actually got time to investigate this stuff

The delivery date was long promised

We're likely gonna deliver garbage and then when the, already semi-planned, continuation of the project starts, we'll throw out the old framework, the old architecture... and maybe even the old hardware.

@LotsOfCaffeine Hehe, so the usual product lifecycle then. Cannot fix old code, no time to write good code.

Mutex deadlocks often happen with cross-allocation. Thread 1 owns mutex A and waits for mutex B, but thread 2 owns mutex B and waits for mutex A.

A very basic approach: always allocate resources in a defined order. If you need to allocate another resource out of order, release the ones you have until you match the order, then reallocate.

In the example, you always could allocate in ascending order. Thread 1 is good, but thread 2 needs to release mutex B (thereby unblocking thread 1), then allocate mutex A, then allocate mutex B.

You would encapsulate that in a dedicated allocator that takes what resources the requesting thread already has and which one it requests. This hides the free/realloc stuff from the threads so that this doesn't sprawl all over the code base.

Did you draw this instead of looking through everything?