Fix threading races on AudioDSPKernelProcessor::m_kernels

Fix threading races on AudioDSPKernelProcessor::m_kernels

AudioDSPKernelProcessor::m_kernels is accessed by the main thread and
the Audio Device thread, and thus should be protected by mutex.

This mutex implementation is consistent with that of ConvolverNode::m_reverb.

See the crash report for more details: https://cluster-fuzz.appspot.com/testcase?key=6662160935550976

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

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

[haraken, 2013-09-04 01:22:26]

kbr: would you take a look?

[haraken, 2013-09-04 16:59:33]

On 2013/09/04 01:22:26, haraken wrote:
> kbr: would you take a look?

rtoy1: Replaced the MutexLock with a MutexTryLock. PTAL.

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

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
File Source/core/platform/audio/AudioDSPKernelProcessor.cpp (right):

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
Source/core/platform/audio/AudioDSPKernelProcessor.cpp:103: void
AudioDSPKernelProcessor::reset()
Please add an assertion that this is called on the main thread -- and run tests
in a debug build.

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
Source/core/platform/audio/AudioDSPKernelProcessor.cpp:129: MutexLocker
locker(m_processLock);
I believe this is called on the audio thread and therefore must use a trylock.

Please add an assertion like ASSERT(context()->isAudioThread()).

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
Source/core/platform/audio/AudioDSPKernelProcessor.cpp:136: MutexLocker
locker(m_processLock);
trylock needed here too.

[haraken, 2013-09-04 19:50:05]

Thanks for reviewing!

kbr: Updated the CL. PTAL.

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
File Source/core/platform/audio/AudioDSPKernelProcessor.cpp (right):

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
Source/core/platform/audio/AudioDSPKernelProcessor.cpp:103: void
AudioDSPKernelProcessor::reset()
On 2013/09/04 18:18:46, Ken Russell wrote:
> Please add an assertion that this is called on the main thread -- and run
tests
> in a debug build.

Done.

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
Source/core/platform/audio/AudioDSPKernelProcessor.cpp:129: MutexLocker
locker(m_processLock);
On 2013/09/04 18:18:46, Ken Russell wrote:
> I believe this is called on the audio thread and therefore must use a trylock.
> 
> Please add an assertion like ASSERT(context()->isAudioThread()).

Done.

https://codereview.chromium.org/23931002/diff/1/Source/core/platform/audio/Au...
Source/core/platform/audio/AudioDSPKernelProcessor.cpp:136: MutexLocker
locker(m_processLock);
On 2013/09/04 18:18:46, Ken Russell wrote:
> trylock needed here too.

Done.

[Ken Russell (switch to Gerrit), 2013-09-04 19:55:22]

LGTM

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

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

[commit-bot: I haz the power, 2013-09-04 20:24:36]

Sorry for I got bad news for ya.
Compile failed with a clobber build on mac_layout.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_layout...
Your code is likely broken or HEAD is junk. Please ensure your
code is not broken then alert the build sheriffs.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2013-09-04 21:36:46]

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

[commit-bot: I haz the power, 2013-09-05 01:24:50]

Change committed as 157256