mudang

I've written an externals which works inside a pfft~. It saves the amplitudes of specific bins (in the perform routine) into an internal array and outputs them as a list, when a bang is received (which is triggered by a metro every 20 ms). This list is used outside the pfft to do polyphonic pitch detection.

As I have to use a rather big fft size (8192), I'm using 8x overlap to get a smaller latency.

Now, I'm not quite sure how the overlap is handled by the pfft~ object. Does my perform routine get called 8 times per 8192 samples ?

Should I use something like mutex or critical regions to protect the internal array from being read (in the message thread) and written (in the perform routine) at the same time ?

perform-routine-in-pfft-with-overlap

One of my first externals was a thing working inside pfft~, and if I remember correctly things are more or less as you say. The only thing is that in your example the perform routine will be called 8 times per 4096 samples - as only the lower half of the FFT is actually sent around, unless you state otherwise (there should be something like a fullspectrum attribute in pfft~ controlling this).

As for the other question, if you have scheduler in audio interrupt AND your bang comes in the high priority thread, you are guaranteed that it will never interrupt, or be interrupted by, the perform routine. Otherwise yes, you should set up a mechanism to protect your data. I'd simply try the lock in the perform routine, in order to skip the writing if someone's reading, rather than blocking the whole audio thread waiting for things to happen elsewhere.

Could you please give a brief example of how to skip the writing when another routine is reading ?

If I understand it right, putting both the write and read loops into a critical region will block the whole audio thread.

But if i just check an internal variable before going into the write loop, that won't make it thread safe, does it ?

as you say, checking a normal variable won't be enough, because its assignment and check themselves can be interrupted by another thread.

You need to use a critical region, or a mutex, or a variable that you increment/decrement atomically.

For most uses, I'd say that mutexes are the best choice. There is plenty of literature on the forum and the internet about them.

// in your object structure
t_systhread_mutex mutex;

// in your new method
systhread_mutex_new(&x->mutex, 0);

// in your bang method
systhread_mutex_lock(x->mutex);
// read your buffer and prepare the atoms to be output
systhread_mutex_unlock(x->mutex);
// output the atoms

// in your perform method
if (systhread_mutex_trylock(x->mutex)
 return w + 2; // or whatever
// copy the vector in the buffer
systhread_mutex_unlock(x->mutex);
return w + 2; // or whatever

And if you resize the pointer in some place of your code, and set some variable to its size, that should be protected as well. Actually, that's the most important thing to protect, as it's the only one that may crash Max - the worst you can get from the others is just some non-consistent data.

this is not the best system ever, as it won't allow the bang method to be entered simultaneously by the main and scheduler thread, but for simple cases it should do.

Hi.
as you say, checking a normal variable won't be enough, because its assignment and check themselves can be interrupted by another thread.
You need to use a critical region, or a mutex, or a variable that you increment/decrement atomically.
For most uses, I'd say that mutexes are the best choice. There is plenty of literature on the forum and the internet about them.

I was a bit puzzled because the SDK docs only mention critical regions in the threading chapter...

systhread_mutex_trylock was the clue, i was missing.

You should be able to do what you need with a critical region as well. just use critical_enter, critical_tryenter and critical_exit in place of systhread_mutex_lock, systhread_mutex_trylock and systhread_mutex_unlock. (I have never used critical_tryenter, but I guess it should work!)

The advantage is that a plain mutex is a much faster locking mechanism than a critical region.

Again, I advise you to look around in the forum and over the internet for more info... this is hard stuff - or, at least, it's been and still is for me!

You should be able to do what you need with a critical region as well. just use critical_enter, critical_tryenter and critical_exit in place of systhread_mutex_lock, systhread_mutex_trylock and systhread_mutex_unlock. (I have never used critical_tryenter, but I guess it should work!)
The advantage is that a plain mutex is a much faster locking mechanism than a critical region.
Again, I advise you to look around in the forum and over the internet for more info... this is hard stuff - or, at least, it's been and still is for me!

perform routine in pfft~ with overlap