[Xenakios]

Originally Posted by mviljamaa

Another is, when there's a data, say a std::vector, that's accessed from the GUI and the audio processing, then how should this be guarded against, so that both cannot read or write it at the same time?

std::vector is like any other variable, so the same rules rules apply as for anything else that must be protected from access by multiple threads at the same time.

IPlug has an internal mutex object per plugin object, that can be used with the IMutexLock object. (That is, when that is instantiated, things are locked until the current scope ends.) More complicated scenarios might require you to manually lock and unlock the internal mutex or even add your own additional mutex objects. But the basic IMutexLock method should be enough for basic stuff. It's very difficult to say when will you need to do the locking, it will completely depend on your particular code and how different threads will be able to change shared variables.

Note that the IMutexLock class is named misleadingly. It is not itself a mutex/lock, it just uses an existing mutex object that it gets from the "this" variable passed into its constructor.

Some example code...

void MyPlug::OnParamChange(int paramIdx) 
{ 
  IMutexLock lock(this);
  ... deal with the parameter change... 
}

void Reset() 
{ 
  IMutexLock lock(this); 
  ... do the resetting stuff...
}


void MyPlug::clear_vector()
{
  // the cout line is executed outside the mutex lock
  std::cout << "Clearing the vector...\n";
  IMutexLock locker(this);
  // Now we are in the locked region until the end of the function
  m_vec.clear();
}

void MyPlugProcessDoubleReplacing(double** inputs, double** outputs, int nFrames);

{
  // "mutex already locked for us", so you don't need to 
  // or even must not lock the IPlug internal mutex here
  // yourself
  if (m_vec.size()==0) { // do whatever to handle the vector being empty... return; }
  // etc
}