Callasync locking?

Hi guys,

Is is correct that MessageManager::callasync does some locking?
The MessageQueue class that is used two keep a list of all messages has a ReferenceCountedArray messages which takes a criticalsection(mutex) to prevent some conclicts with reading and writing to this array.

Could this be a problem or am I just afraid for nothing…?

Thanks in advance,

What does the implementation of callAsync() do? Do you see any locking happening in the implementation?

Well… callAsync creates an AsyncCallInvoker on the heap (which is also not so nice if you call that on the audio thread). And that class calls the post() method from MessageBase which calls postMessageToSystemQueue(), which calls post() on a MessageQueue, which then adds the messagebase to an array which takes a criticalsection.
So that array uses locking. But maybe this is just a small, fast, lock.

I think it’s dangerous to assume that a lock will be fast or not… maybe it will be fast 99.9% of the times, but then you still have problems 0.1% of the time, which is not acceptable for an audio plugin.
I am also using juce::MessageManager::callAsync in the audio thread, but since I see that it allocates memory on the heap (that probably involves locking, too, btw) and uses a lock afterwards, I’ll replace it with some other mechanism.

1 Like