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

[bugzilla-daemon at webkit.org]

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





--- Comment #18 from Stephen White <senorblanco at chromium.org>  2013-02-14 03:39:20 PST ---
(From update of attachment 188163)
View in context: https://bugs.webkit.org/attachment.cgi?id=188163&action=review

>>>> Source/WebCore/platform/graphics/chromium/ImageFrameGenerator.cpp:227
>>>> +    return m_hasAlpha;
>>> 
>>> I know I'll regret asking this, since threading has a long history of making me look like an idiot, but why do you need to lock the mutex for a read?  It's a bool, so all reads should be atomic anyway, no?
>> 
>> reading a bool should be atomic, but I am not sure whether this is the case with multi-core processor cache.
>> If read/write are on different processors, this probably might not hold.
> 
> In addition to processor cache, there could be other factors that cause out-of-order execution: pipelining, cache, optimization etc. In such cases, when we set the boolean to false, the code before the set statement might not have been executed yet.

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.