[Webkit-unassigned] [Bug 34912] audio engine: add ReverbConvolver class

[bugzilla-daemon at webkit.org]

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





--- Comment #32 from Jeremy Orlow <jorlow at chromium.org>  2010-03-30 07:50:36 PST ---
> > IIRC, it's better to signal outside of the lock so that it doesn't wake up, try
> > to get the lock, and then sleep again.
> > Also, use MutextLocker with {}'s to scope it.
> 
> I'm pretty sure it has to be signaled inside the lock which is the pattern I've
> seen in other code like this, and also seems to be the pattern used elsewhere
> in WebKit.

Doing so seems always safe, so I'm fine leaving things as is and not trying to
over-optimize.

> 
> > I'm pretty sure you can simply set the variable to try and send the signal
> > (without the try lock here).  As long as the consumer has something that causes
> > a read barrier (which I believe the mutex will) you should be OK.  It might be
> > a good idea to write a simple app to verify all this threading stuff (whether
> > you go with your model or my suggestion) works as expected though.  :-)
> 
> I think there are some race conditions which can happen if you don't actually
> get the lock here.

Sure, but what you have right now is a race condition as well.  That said, I
guess I don't think making a race condition more subtle is much help.

Are you sure you're not being overly paranoid about the lock?  I suppose it's
possible that one of the background threads could take the lock and then do a
context switch in the couple instructions before the lock is given up, but that
seems fairly unlikely.  And modern OSs have heuristics to try and avoid stuff
like that, typically.

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