[cairo] Fixing concurrency bugs in cairo's reference counting

[Carl Worth]

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
> fetch
> 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
ATOMIC_DECREMENT_IS_ZERO.

> 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>
where available).

Sound reasonable?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20061218/b1fa7581/attachment.pgp