Deadlock when using multiple OpenGLRenderer components as children of a non openGL component

[timart]

I am in the process of implementing a single OpenGLContext based rendering system like the one described by @TonyAtHarrison. Tony, your description above is extremely helpful, but I have a question. You stated that to add/remove renderers at run-time, you had to create some kind of synchronization system since these requests would be run on the Message thread while the GL thread could also be accessing the renderer queues.

@TonyAtHarrison

OPTIONAL : Our plugins have features that require adding, removing, and re-ordering the renderers at run-time. Because these operations would come from the main thread, I had to essentially make two OpenGLRenderer* queues and add methods that atomically let you add/remove renderers. The methods use std::atomic_flag to ensure that only one thing is manipulating the queues at a time, letting us properly set up or tear down the target renderers. For example, if you were to add a renderer while the OpenGL loop is running, you couldn’t call its renderOpenGL() method until calling its newOpenGLContextCreated() method (assuming the renderer needs to allocate buffers etc., which is usually the case). Similarly, renderers in the removal queue have their renderOpenGL() callback called for the last time followed by openGLContextClosing() and are then subsequently removed from the renderers array.

Is this synchronization unnecessary since the OpenGL thread holds a MessageManager::Lock while calling renderOpenGL?

@TimArt

it seems this is the case since in juce_OpenGLContext.cpp the renderFrame() method begins by getting a Message Manager lock:

bool renderFrame()
{
    MessageManager::Lock::ScopedTryLockType mmLock (messageManagerLock, false);
    ...
}

There was a previous post I made asking if accessing Message thread data (Component width/height) in renderOpenGL() was a race condition, but I was told it was not because the GL thread holds a Message thread lock whenever it calls renderOpenGL():

OpenGL Render Thread Resizing when Component Resized

Hello all, I am writing an OpenGL audio visualizer and using the OpenGLRenderer to have a separate render thread for OpenGL. Just as shown in OpenGLDemo.h in the JUCE demos, I want to have my OpenGL rendering scaled to fit the Component size. In OpenGLDemo.h, in the OpenGLRenderer::renderOpenGL() method it uses the following code to set the OpenGL viewport to match the component size: auto desktopScale = (float) openGLContext.getRenderingScale(); ... glViewport (0, 0, roundToInt (desktopScale…

From what I understand, if you were adding, removing, or re-ordering renderers at run-time from the message thread in a system as you describe, @TonyAtHarrison:

• When adding a new renderer at runtime, you could call the renderer’s newOpenGLContextCreated() method and then immediately add it to the array of renderers.
• When removing a renderer, call its openGLContextClosing() method and immediately remove it from the array of renderers
• When re-ordering, you would simply just swap various positions in the array of renderers.
• And all of this functionality could happen without needing any synchronization such as locks or atomic variables.

I may be completely misunderstanding this, but would love to know if my thinking here is wrong so I can correct my assumptions. Thanks for any help here!