[Mesa-dev] [PATCH 06/13] mesa: Replace sampler object locks with atomic inc/dec.
t_arceri at yahoo.com.au
Mon Aug 10 15:33:02 PDT 2015
On Mon, 2015-08-10 at 09:16 -0700, Matt Turner wrote:
> 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?
> 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
Looking over this again what your saying looks correct. I had convinced myself
I doubt it will register anything on your benchmark but I also noticed the
wrapper around the _mesa_reference_sampler_object call isn't required at least
for samplerobj it may also be the case elsewhere I haven't checked yet.
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
More information about the mesa-dev