On Thu, Jan 16, 2014 at 10:31 AM, Raine M. Ekman <raine@iki.fi> wrote:
I get the point that mutexes are bad... but how bad exactly? I have one here:

There's a QMutex controlling access to the OPL2 emulator, without it LMMS would crash if there are 2 copies of the plugin active (thread problem?), so by my reasoning that's better than without one, at least as a short term solution.
The issue is one of threading in this case: if two threads use the same data (one reading, one writing) then a segmentation fault occurs. This *will* happen, if you don't protect the memory in question with a mutex. As to your reasoning above: yes, no crashing is better than crashing! :)

The bigger issue is how to design real-time safe code. Locking mutexs *can* actually be real-time safe: but its a minefield, that I strongly advise staying away from. If static data exists in a plugin, then it will be shared with other plugin instances: that is the origin of the issue: so duplicate data for each instance. Using more memory will fix the problem in this case.

Note: There is another issue in the code here:
"new" is used, which is a function that has "unbounded time". Basically, it may *not* be used in a real-time context: memory allocation / deallocation will cause glitches / xruns, as this function doesn't return immidialtly from the kernel: it may delay for an unspecified maximum time.
The alternative would be fixing the chip emulation so this isn't needed. Any hints on what to look for (or tools to do the looking)?
Didn't look at the code, but see above on duplicating data per instance. Note, two threads can *read* concurrently: if there is static data, that will *never* be written to, then it is safe to access it from both plugin instances.
Note also, that this issue will only arise when the host program is multi-threading its processing function. (Otherwise how could there be 2 plugins executing at the same time?)

HTH, -Harry