Questions about juce_IIRFilter and concurrency programming


#1

Hello everybody !

I have been studying filters and concurrency programming a little. I still don’t get everything from TheVinn discussions, about lock-free FIFOs and all that stuff ( :lol: ), but I have understood a few things. Then, I have looked for the class IIR filter that Jules has developed, to grab some information about what I should do in my plug-ins. So, I have a few questions about this class.

  1. The class uses a CriticalSection, and the process is locked in its functions setCoefficients, copyCoefficientsFrom, makeInactive, reset, processSamples and in the destructor. If I make the choice of using critical sections in my plug-in instead of atomic variables or lock-free algorithms (like in VFLib), do I need to protect as many functions as I can see there ?

  2. What should I do to evaluate the efficiency of any concurrent system ? I have well understood that the programs which need the most attention have to be more complicated than a simple filter (like a DAW, a modular synth, or effects like multi-threaded partitioned convolution…). But, if I use say 100 plug-ins in my sequencer, with 80+ % of CPU consumption in my project, and then if I instanciate a plug-in using a 2nd order filter, does the choice of one algorithm or another for concurrency will change something ?

  3. Is there a simple and more robust way to protect the processes of this class than what has been done, using only JUCE classes ?

EDIT : I’m creating a new subject for the TDF2 implementation


#2

Well if you have questions you should post them. You don’t need to worry about the actual implementation, only the interface. It “just works”


#3

I know, I know, but I still need a little more understanding to know if it is useful for me :wink: I don’t want to destroy one fly with a nuclear bomb, and to put VFLib in all my JUCE projects :mrgreen: I will ask you some specific questions later :wink:


#4

If you want to follow the best practices listed here then you will need a thread queue.

http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing

Comparing the implementation of a concurrent audio system to a “fly” is totally inaccurate. Multithreaded programs have an inherent level of complexity that unusually high. I am reminded of this great article by Herb Sutter:

The Trouble With Locks


#5

I have read these articles yet, thanks :wink:

What I mean is that the need of an advanced concurrent system implementation, like the one you have proposed, is justified only for software with a given complexity. Until now, I have never had to read anything about lock-free algorithms, and I have never had any issue in my plug-ins because of priority inversions or ABA problems. The day I will be able to see a problem related to the basic multi-threaded implementation I have done, I will reconsider that. And I know I won’t be able to avoid this issue forever :mrgreen:

Anyway, any opinion about the questions I have asked previously ? :wink:


#6

somehow your questions are little bit confused…

  1. you have to “protect” any functions which shouldn’t run at the same time, if there is no chance that there are called at the same time, you don’t have to “protect” them ??
  2. these are 1000 question in one, not sure what your talking about…
  3. I would say using a critical section to avoid concurrent processing of the same data structure is the simplest solution
    The are reasons like priority inversion, which makes critical section sometimes problematic, than you have to choose lock-free algorithm.

#7

Thanks for your answers :wink:

About the question 2, I would like to know what I can do to make a plug-in “crash” or “glitch”, with a given concurrent implementation, and because of concurrent programming issues. I mean, ok the simplest solution is to use critical sections, and lock-free algorithms are one logical and efficient way to do these things. But how can I know that another simpler implementation in a given plug-in will be still fine or not ? I hope it’s clear…