[Bug]: using ThreadSafeListener still triggers assert when calling from 2 threads

Detailed steps on how to reproduce the bug

using ThreadSafeListener should prevent from triggering an assert when calling from multiple threads (as per indication in the assert comments), but it still trigger it.

_EDIT : Reading the ListenerList function where it happens, the ScopedTryLock on line 233 of juceListenerList.h is intriguing to me. Shouldn't there be a function that blocks and ensure the lock is gained (so ScopedLock) when we're using CriticalSection ? Right now, I don't really see what's the actual function of ThreadSafe except telling me that it may not be safe.

Minimal test case :

3 Classes : TestClass, TestThread and TestListener
TestClass extends TestListener, contains 2 instances of TestThread
TestClass has a ThreadSafeListenerList, and added itself to this list.
the 2 TestThread instances are continuously calling the testClass "notify()" function
the notify() function in TestClass calls the listeners TestListener::notified() function
This triggers the assert in juce_ListenerList line 232 warning about multiple threads calling at the same time and advising to use LightListener or ThreadSafeListener

This is a visual representation of the above description :

Flowchart

I believe this should not trigger the assert, and in scenarios where calls are done repeatedly, this makes impossible to debug as the assert will stop the program every time.

here is the full code :

#include <JuceHeader.h>
#include "MainComponent.h"

class ScriptTestApplication;

class ThreadTest : public juce::Thread
{

public:
    ScriptTestApplication* test;

    ThreadTest(ScriptTestApplication * test) : juce::Thread("ThreadTest"), test(test)
    {
        startThread();
    }

    ~ThreadTest()
    {
        signalThreadShouldExit();
        waitForThreadToExit(-1);
    }

    void run() override;
};

class TestListener
{
public:
    virtual ~TestListener() {}
    virtual void notified() = 0;
};

class ScriptTestApplication : public juce::JUCEApplication, public TestListener
{
public:
    ScriptTestApplication() :
        threadTest1(this),
        threadTest2(this)
    {}

    const juce::String getApplicationName() override { return ProjectInfo::projectName; }
    const juce::String getApplicationVersion() override { return ProjectInfo::versionString; }
    bool moreThanOneInstanceAllowed() override { return true; }

    ThreadTest threadTest1;
    ThreadTest threadTest2;
    juce::ThreadSafeListenerList<TestListener> listeners;

    void initialise(const juce::String& commandLine) override
    {
        listeners.add(this);
    }

    void notify()
    {
        DBG("Notify : " << (int)juce::Thread::getCurrentThreadId());
        listeners.call(&TestListener::notified);
    }

    void notified()
    {
        DBG(" > Notified : " << (int)juce::Thread::getCurrentThreadId());
    }

    void shutdown() override
    {
    }

    //==============================================================================
    void systemRequestedQuit() override
    {
        quit();
    }

    void anotherInstanceStarted(const juce::String& commandLine) override
    {

    }

};
START_JUCE_APPLICATION(ScriptTestApplication)

void ThreadTest::run()
{
    while (!threadShouldExit())
    {
        test->notify();
        wait(2);
    }
}

Operating systems

Windows

What versions of the operating systems?

Architectures

64-bit

Stacktrace

No response

Plug-in formats (if applicable)

No response

Plug-in host applications (DAWs) (if applicable)

No response

Testing on the `develop` branch

The bug is present on the develop branch

Code of Conduct

[X] I agree to follow the Code of Conduct

juce-framework / JUCE