@CodeSpirit the only reason you even know about the existence of the private method is cause you decompiled or had access to the code. If that wasn't the case, you wouldn't have the problem now. The private method may change or be deleted in the future, you shouldn't relay on its existence.

Sounds to me like the private modifier is doing exactly what it is supposed to do.

@Caleth why do you assume there's no synchronisation? Also you overestimate the performance overhead of synchronison. The difference between mutex and no mutex was within the margin of error, less than 1ms. The library is used in real time applications, with hard performance targets of 6ms. Exceeding 6ms leads to... unfortunate scenarios

@Caleth added some clarifications

+1 a lot of people forget about the complete part.

This is thread safe, while simultaneously belonging to stackoverflow.

@user877329 the image looks fine to me.

Do you care about a programming language in particular?

@pjc50 if you can recover that easily you can always wrap your main / message loop in a try-catch and rollback global state to a known working restore point without needing to crash in the first place. If you stick to RAII C++ (no pointers and malloc), objects get automatically deleted when the stack is unwinding looking for an exception handler. C++ is much safer than you give it credit for. If we're talking about C, then yes, things get sticky, but then again pure C doesn't have exceptions in the first place, so you should stick to exception-free code if you plan on using C in C++ code.

This is the best answer so far. +1

@Caleth Can you give example of "IO" that is multithreading friendly? If you do multithreading, you usually spawn workers to do stuff to individual datasets. You do not want shared states between workers, as that will nullify the performance advantage of threads due to locking. So when one worker fails to process a dataset, that will not alter any global state. ACID compliant data stores will have rollback capabilities, so your state change failures are contained.

If reverse engineering were illegal, all engineers (not just software engineers) would be out of a job and we'd still be living in caves. Thankfully that's not the case.

It seems like your threads are wrapped within objects of some sort, exposing a make method. If so, take a look at the futures / promise API, these catch the exceptions and contain them within the local state of the thread, and later exposes them as properties in the futures/promise object. This allows the callers to be aware of the failure without crashing the application. You can implement something similar, or rearrange your code based on futures / promises.

In most cases you will log and move on, without crashing what is potentially a sensitive application. Crash happy applications have a quick way to the recycle bin of engineering failures. Most exceptions are recoverable, and in a multi threading environment, assuming no global state has been altered, exception handling and recovery is surprisingly easy - you don't care if an exception is thrown as long as it is contained in a single thread. Just retry and move on.