False negative result in ParameterThreadSafetyTest() - the locks wait() and signal() don't meet

[TheMates]

Hi,
I am testing my plugin and getting false negative result on the ParameterThreadSafetyTest()

-----------------------------------------------------------------
Starting tests in: pluginval / Parameter thread safety...
*** FAILED: Timeout after 30 secs

Finished validating: C:\Program Files\Common Files\VST3\Audified\U73b Compressor.vst3\Contents\x86_64-win\U73b Compressor.vst3
*** FAILED WITH EXIT CODE: 1

Finished batch validation

I think that it might happen to some more cpu intensive plugins that take more time in processing.

I think this block might finish

pluginval/Source/tests/BasicTests.cpp

Lines 624 to 634 in b107dd2

	// This emulates the plugin itself setting a value for example from a slider within its UI
	juce::MessageManager::callAsync ([&, threadRandom = r]() mutable
	{
	startWaiter.signal();
	for (int i = 0; i < numBlocks; ++i)
	for (auto param : parameters)
	param->setValueNotifyingHost (threadRandom.nextFloat());
	endWaiter.signal();
	});

before the main thread gets to endWaiter.signal(); at the end of this block and we never get the endWaiter.signal() while the main thread is waiting.

pluginval/Source/tests/BasicTests.cpp

Lines 651 to 667 in b107dd2

	startWaiter.wait();
	for (int i = 0; i < numBlocks; ++i)
	{
	// Add note off in last block if plugin is a synth
	if (isPluginInstrument && i == (numBlocks - 1))
	addNoteOff (mb, noteChannel, noteNumber, 0);
	for (auto param : parameters)
	param->setValue (r.nextFloat());
	fillNoise (ab);
	instance.processBlock (ab, mb);
	mb.clear();
	}
	endWaiter.wait();

I am not an expret in threading and in using JUCE thread classes, but when I decreased the number of cycles in the main loop

pluginval/Source/tests/BasicTests.cpp

Line 653 in b107dd2

for (int i = 0; i < numBlocks; ++i)

to something like 10-20, the test finished successfully. I am not sure now how to fix it, but someone might be able to figure this out.

[drowaudio]

Hmm, I'm not sure that's actually possible.
The main thread (the callAsync block) will signal those two events and the background thread which the test is running on will wait for them in turn.

If the background (test) thread gets to the waiters first, it will wait. If they've already been signalled by the main thread, it will just run over them.

---

If you pause the debugger whilst the test is running, can you see what each thread is doing?