[Mesa-dev] [PATCH 06/13] mesa: Replace sampler object locks with atomic inc/dec.

[Matt Turner]

On Fri, Aug 7, 2015 at 10:09 AM, Ian Romanick <idr at freedesktop.org> wrote:
> I know we've talked about this about 100 times, but something in the
> back of my mind tells me that we have a pre-existing race.  What happens
> if the p_atomic_dec_zero happens on thread A while thread B is between
> the _mesa_lookup_renderbuffer call and the _mesa_reference_renderbuffer
> call on the same object?  Won't thread A free the memory out from under
> thread B?

Generally:

RefCount is initialized to 1 (in all cases but renderbuffers... that
might be a bug -- did you choose renderbuffers in your example for
this reason?). When Bind is called the first time, RefCount is
incremented to 2.

When Delete is called, RefCount is decremented -- RefCount only goes
to 0 only if the object isn't bound anywhere, in which case it's
actually deleted. If The object is still bound somewhere and RefCount
is decremented to non-zero, the object cannot be rebound and will be
deleted when its last reference is unbound.

Commit 42aaa548 changed the renderbuffer code from RefCount = 1 to =
0. It seems pretty clearly wrong to me, since a
glGenRenderbuffers()/glDeleteRenderBuffers() pair would fail to
actually delete the renderbuffers. Does anyone else read it
differently?