Reaper JS concurrency

[Chris-S]

Hi,
Concerning the official JSFX doc, the @gfx section is running in a separate thread.

Note that this code runs in a separate thread from the audio processing, so you may have both running simultaneously which could leave certain variables/RAM in an unpredictable state.

But it is also said, that the atomic_ functions are not needed to use:

Guaranteed-atomic updates/accesses of values across contexts (specifically @gfx and other contextes). Normally these are unnecessary

So, I'm confused. Is it okay for example to calculate a sum of samples in @sample:

sum += mysample;
samplecnt += 1;

and in @gfx:

avarage = sum / samplecnt;
sum = samplecnt = 0;

[1] http://www.reaper.fm/sdk/js/js.php

[Mayae]

Your specific example is not okay.
Normally these are unnecessaryBecause normally you don't write code spanning/shared-by multiple execution contexts (threads). When they do, you have to use atomics.

[camsr]

Write the results to a variable that is only read by the gfx section.
This is a very basic example.

sum += sample;
samplecount += 1;
sum_gfx = sum;
samplecount_gfx = samplecount;

[Mayae]

Write the results to a variable that is only read by the gfx section.
This is a very basic example.

sum += sample;
samplecount += 1;
sum_gfx = sum;
samplecount_gfx = samplecount;

If we were talking x86 C/C++/assembly one could neglect the possibility of torn read and writes, but for any other undefined (and more complex) language with interpreted/dynamic properties where a inc statement results in a lot of code, I would not advice this.

[Chris-S]

Write the results to a variable that is only read by the gfx section.
This is a very basic example.

sum += sample;
samplecount += 1;
sum_gfx = sum;
samplecount_gfx = samplecount;

Yes, I think this is sufficient to keep wrong values at minimum.
Also I will change my code so that in @gfx there are only reads (no writes) to globals.

Using real mutexes in the audio thread (@sample) is not a good idea IMHO.

[camsr]

I made a peak meter plugin based on OpenGL once, and it had a problem with asynchronisity... some peak values were missed. So I used the max value from the audio process instead, which worked, but looked very out of sync with large buffer settings. Don't try to pass too much data to the gfx section, just the bare essential, and keep the rest of the processing in the audio section.