[cairo] Locking policy

[Carl Worth]

On Sun, 26 Jun 2005 21:29:41 -0700, Keith Packard wrote:
> First off, we need to list all of the mutexes and either assert that
> there are no simultaneous locks or define a locking order when there
> are.

I've been through all the hashes now, (they were caches before), and I
believe they are correct.

There are still locks in the remaining caches, (there are 3), that I
have not looked at in great detail.

> The case that I found this evening was in the unscaled font cache;
> ejecting an entry from that cache is done (oddly enough) with the cache
> lock held, but the act of removing an entry from the cache attempts to
> re-acquire the lock.  Oops.

This seems to be the one that was easiest to hit. I enabled the
mutexes again and made the tests link against -lpthread when it's
available (this is now committed).

Sure enough, if I roll back cairo to just before the unscaled_font_map
patch which I recently committed, 'make check' deadlocks on every test
that draws test. But, happily, just after the unscaled_font_map patch,
there are no deadlocks triggered by 'make check'.

> I'm afraid most of this process is just tedious review work, not
> exciting new development, but ensuring that cairo is deadlock-free is
> rather important.

Indeed. I've spent a lot of time on this over the past few weeks. I
would be happier if the rest of the cache rewrite were done, (we still
need to finish it for performance reasons). But I also wanted to get
as much mutex-enabled testing as possible. So I just released 0.9.2
and encouraged people to test it with threaded applications.

-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/20050813/f7c00c55/attachment.pgp