Doesn’t G’MIC has a built-in lock when it comes to using multiple threads within fill/eval/new_image to make it thread-safe? And can we disable it as a option? Would that provide performance boost? I know if given the option, I know exactly what to do to avoid problems with this. Mainly, if I don’t expect to write on the same resource, I can definitely take the lock off.
It has critical() which ensures that the code block inside is only executed by a single thread at a time.
I know about critical(), but it isn’t related. I’m talking about lock used often in multi-threading programs and whether G’MIC utilize this same mechanic on multi-threaded codes.
Also, critical slows down my code in test. So, it isn’t what I’m looking for.
Of course critical() slows down the code, as it makes all threads (but one) wait for the execution of the code inside. That’s precisely what mutexes are for : they allow the access to a ressource (variable or memory slot) only by a single thread.
To me, that’s the definition of a mutex lock. I’m not sure what you are looking for otherwise.