Fix threading races on ConvolverNode::m_reverb in ConvolverNode::latencyFrames()

Fix threading races on ConvolverNode::m_reverb in ConvolverNode::latencyFrames()

According to the crash report (https://cluster-fuzz.appspot.com/testcase?key=6515787040817152),
ConvolverNode::m_reverb races between ConvolverNode::latencyFrames() and ConvolverNode::setBuffer().
This CL adds a proper lock for ConvolverNode::m_reverb.

BUG=223962
No tests because the crash depends on threading races and thus not reproducible.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=157245

[haraken, 2013-09-04 00:32:43]

PTAL.

[haraken, 2013-09-04 00:47:55]

kbr: would you take a look?

[haraken, 2013-09-04 16:57:53]

On 2013/09/04 00:47:55, haraken wrote:
> kbr: would you take a look?

rtoy1: Replace the MutexLock with a MutexTryLock. PTAL.

[Raymond Toy (Google), 2013-09-04 17:11:35]

On 2013/09/04 16:57:53, haraken wrote:
> On 2013/09/04 00:47:55, haraken wrote:
> > kbr: would you take a look?
> 
> rtoy1: Replace the MutexLock with a MutexTryLock. PTAL.

lgtm.  Perhaps use std::numeric_limits<double>::infinity() instead of DBL_MAX?

[Ken Russell (switch to Gerrit), 2013-09-04 18:13:21]

LGTM with rtoy's review feedback addressed.

Also please see comment on related CL https://codereview.chromium.org/23926002/
.

[haraken, 2013-09-04 19:46:26]

Thanks for reviewing! Changed it to std::numeric_limits<double>::infinity().

[commit-bot: I haz the power, 2013-09-04 19:46:56]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/haraken@chromium.org/23514037/10001

[commit-bot: I haz the power, 2013-09-04 21:23:16]

Change committed as 157245