[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 #20 from Stephen White <senorblanco at chromium.org>  2013-02-14 09:34:01 PST ---
(In reply to comment #19)
> 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.

I think you're confusing out-of-order execution with multithreading.  Out-of-order execution only means that 
instructions can be reordered on the processor if they have no effect on apparent program order.  I.e., you can hoist a read above an ALU op, as long as there are no data dependencies between them. The instructions are still retired in program order.  Cache coherence ensures that this holds across processors as well.

> 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. 

Right, that would be problematic, but that's not the case here:  you only have the mutex protecting one write to the variable, and one read, not two writes.  As I said before, I don't think the mutex protecting the read is doing anything, but that is processor-dependent and harmless I guess.

Anyway, this is getting way off topic for the code review, and my r+ still stands.

> 
> (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.