MultiThreadedCompositor deadlocks

The easiest way to reproduce is to use double buffering - src/server/compositor/buffer_stream_factory.cpp:

auto switching_bundle = std::make_shared<mc::BufferQueue>(3, gralloc, buffer_properties, *policy_factory);

auto switching_bundle = std::make_shared<mc::BufferQueue>(2, gralloc, buffer_properties, *policy_factory);

Then:

mir_demo_server_shell --display-config=sidebyside
mir_demo_client_egltriangle -n

In the shell: ALT+Ctrl+<arrow keys> to change orientation which will restart the compositor.

It's a race between 3 threads:

Thread A owns SceneObserver::mutex, responding to a frame_posted notification, waiting to acquire CompositingFunctor::run_mutex (MultiThreadedCompositor::schedule_compositing)

Thread B owns CompositingFunctor::run_mutex and it's waiting to acquire RenderingTracker::guard (due to display_buffer_compositor_factory->create_compositor_for(buffer);)

Thread C executing display_buffer_compositor->composite(), owns RenderingTracker::guard and its waiting to acquire SceneObserver::mutex