[regression] [BufferQueue] Race condition in BufferQueue::compositor_acquire could underflow shared_ptr refcount and delete prematurely, crash.

My understanding is that std::shared_ptr can handle the scenario described in a thread-safe manner without any external synchronization (the control block of a shared_ptr which is what is shared between instances is thread safe).

However, there may still be some races around compositor_acquire() and resizing in give_buffer_to_client() that need further investigation.

AIUI the standard only guarantees that you can update and access two shared_ptr<>s to the same object safely in different threads.

You can't copy construct a shared_ptr<> in one thread while updating the source in another thread.

If I've understood the discussion then:

   auto const& acquired_buffer = buffer_for(current_compositor_buffer, buffers);

should be:

   auto const acquired_buffer = buffer_for(current_compositor_buffer, buffers);

(And the RVO should elide any wasted copies.)

> AIUI the standard only guarantees that you can update and access two shared_ptr<>s to the same object safely in different threads.

You can also create two different shared_ptr<>s from the same source in different threads (assuming a const source, of course), which is what the scenario in the bug describes.

> You can't copy construct a shared_ptr<> in one thread while updating the source in another thread.

Agreed. That's the reason for the "there may still be some races around compositor_acquire() and resizing in give_buffer_to_client() that need further investigation" comment.

OK I misunderstood that the problem was that the reference was to a mutating pointer. As that isn't the case then there's no problem with the timing of copying the smart pointer and the description is wrong.