[webkit-reviews] review granted: [Bug 229168] Make ThreadSafeRefCounted::deref race condition safe : [Attachment 435753] Patch

[bugzilla-daemon at webkit.org]

Geoffrey Garen <ggaren at apple.com> has granted Ryosuke Niwa <rniwa at webkit.org>'s
request for review:
Bug 229168: Make ThreadSafeRefCounted::deref race condition safe
https://bugs.webkit.org/show_bug.cgi?id=229168

Attachment 435753: Patch

https://bugs.webkit.org/attachment.cgi?id=435753&action=review




--- Comment #10 from Geoffrey Garen <ggaren at apple.com> ---
Comment on attachment 435753
  --> https://bugs.webkit.org/attachment.cgi?id=435753
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=435753&action=review

r=me

> Source/WTF/wtf/ThreadSafeRefCounted.h:78
> +	   // Using s_deletionHasBegunRefCount instead of 0 prevents double
delete. See webkit.org/b/201576.
> +	   unsigned refCountToBeginDeletingThis = 1;
> +	   if (m_refCount.compare_exchange_strong(refCountToBeginDeletingThis,
s_deletionHasBegunRefCount, std::memory_order_acq_rel))
>	       return true;
> -	   }
>  
> +	   m_refCount.fetch_sub(1, std::memory_order_release);
>	   return false;

I think we might be able to make this more efficient by doing a naked load,
then branching to decide whether to take the delete or decrement path, then
doing a compare_exchange to commit our decision, then looping if the
compare_exchange fails. That way, in the normal non-deleting case, there's only
one atomic refcount change instead of two.