[cairo] Fixing concurrency bugs in cairo's reference counting
cworth at cworth.org
Mon Dec 18 12:39:33 PST 2006
On Mon, 18 Dec 2006 12:03:14 -0800, Jamey Sharp wrote:
> I'm not sure if this is the same thing Kristian just pointed out, but a
> decrement and test implemented like this is not safe:
> atomically fetch, decrement, store
> test against 0
> If the reference count is 2, then two threads might execute the
> decrement before either re-fetches the value. Then both see 0 and the
> memory is freed twice. But I wouldn't count on the compiler generating
> the right thing given an atomic_decrement function or macro and a
> subsequent test.
Thanks for pointing this out.
So we could write ATOMIC_DECREMENT and ATOMIC_INCREMENT to return the
final value, (too bad it's not easy to write a macro to return a
value, but maybe we can start relying on inline functions for this).
Or maybe we just leave those two as void and add
> The Linux kernel function atomic_dec_and_test, in <asm/atomic.h>,
> atomically decrements, but leaves the new value in a register, so it
> needn't re-fetch. (Actually, on x86, it only leaves the zero-flag set.)
Thanks for pointing that out.
So what I think I'll start with is a general implementation of
ATOMIC_INCREMENT and ATOMIC_DECREMENT_IS_ZERO based on a single
CAIRO_MUTEX protecting all atomic increments and decrements. That
should work anywhere. And then we can easily replace this with more
efficient things, (such as atomic_dec_and_test from <asm/atomic.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061218/b1fa7581/attachment.pgp
More information about the cairo