On Thu, May 15, 2008 at 1:32 PM, Behdad Esfahbod <<a href="mailto:behdad@behdad.org">behdad@behdad.org</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I know I thought of a problem before... Here it is.  In your loop:<br> <div class="Ih2E3d"><br> +    while (solid_surface_cache.size) {<br> +       cairo_surface_t *surface = solid_surface_cache.cache[solid_surface_cache.size-1].surface;<br> +       solid_surface_cache.size--;<br> +<br> +       /* release the lock to avoid the possibility of a recursive<br> +        * deadlock when the scaled font destroy closure gets called */<br> +       CAIRO_MUTEX_UNLOCK (_cairo_pattern_solid_surface_cache_lock);<br> +       cairo_surface_destroy (surface);<br> +       CAIRO_MUTEX_LOCK (_cairo_pattern_solid_surface_cache_lock);<br> +    }<br> <br> </div>solid_surface_cache.size is not declared volatile, so compiler is free<br> to replace that with a simple countdown loop, but since it may be<br> modified from other threads, you may end up destroying an entry twice.<br> Or things like that.<br> <div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>Surely the calls to unlock and lock prevent that optimization? Data that's protected by explicit synchronization shouldn't need to be declared volatile.<br> </div></div><br clear="all">Rob<br>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]