[Webkit-unassigned] [Bug 108892] Passing alpha to DeferredImageDecoder once decoding completes

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Feb 14 08:46:19 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=108892





--- Comment #19 from Min Qin <qinmin at chromium.org>  2013-02-14 08:48:36 PST ---
In out-of-order execution, if you have some code like:

do_sth_to_beta();
alpha=true;     

when alpha=true is executed, you cannot guarantee that do_sth_to_beta() is finished.
And on another thread, if you have

if(alpha) {
  beta=false;
}
This is problematic. Since do_sth_to_beta() could be still running, so setting beta to false will have an adverse effect on that call. 


(In reply to comment #18)
> 
> Looks like I was wrong in the general case anyway:  although for the vast majority of CPU architectures, a single read or write of machine word or smaller is guaranteed atomic, this is still technically processor-specific, and not guaranteed by C++.
> 
> However, I don't understand what you mean by "the code before the set statement might not have executed yet".  Do you mean, the call to !fullSizeBitmap.isOpaque()?  That seems to be the only thing that the mutex protects:  that m_hasAlpha is set to the value of !fullSizeBitmap.isOpaque() atomically.  The call to hasAlpha() could come in on another thread before or after that change to the value, and it might return true or false depending on thread ordering.  The only thing the mutex ensures is that it won't occur during !fullSizeBitmap.isOpaque() or the assignment.  If that's the intent, sorry for the tangent.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list