Re: New proposal for fixing race conditions

On Tue, Jul 23, 2013 at 3:24 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> On Tue, Jul 23, 2013 at 12:11 PM, Chris Wilson <cwilso@google.com> wrote:
>
>> I've been hanging back from this discussion a bit, but I feel the need to
>> express my own take (since I come at the API from a very different
>> perspective than Chris).
>>
>> I understand (and support) Robert's initial introduction of this issue
>> (first line of
>> http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0644.html) -
>> we should avoid having internal implementation details affect observable
>> output.  However, that's not the same thing as "we must prevent any
>> possible race conditions" - in this case, the race condition is between the
>> Web Audio "thread" and the main execution thread.  This is not so much
>> about internal implementation details as it is about the fact that Web
>> Audio developers need to have their expectations set around interactions
>> with the audio "thread".
>>
>
> Let's first agree on the terminology we're using.  Let's define the
> following terms as below, just so that everybody is on the same boat in
> this discussion:
>
> * Data race issue: the problem where one thread is reading to the same
> memory buffer as another thread is reading from it.  Whether the reader
> thread sees the old or new data depends on the timing of the two threads
> being scheduled on the processor(s).
> * Non-deterministic order of execution: If you have multiple asynchronous
> tasks in progress, the order in which those operations occur is
> non-deterministic.
>
> I'm only focused on the first problem here, not at all on the second one.
> If you meant data race issues in "we must prevent any possible race
> conditions", I entirely agree.  If you meant the problems caused by
> non-deterministic order of execution, I don't think we should do that.
> That is an inherent property of the Web platform already.
>

Ehsan, although I agree with your distinction here in the general case, and
I certainly wouldn't advocate for any racy programming practice which would
cause crashes, or modify structs in one thread while another thread is
reading it.  And I also certainly agree that operating systems provide
mechanisms such as locks to avoid these kind of data races, which I'm very
well acquainted with.

But the current situation is *not* in the same category of race.

What we're talking about here is *not* modifying data structures, but
access to PCM data which involves timing.  This timing aspect and the
potential for there to be mistakes in JavaScript code involving it make the
current topic of discussion much more akin to what you've labelled
"Non-deterministic order of execution" above.

In other words, yes there is the (very unlikely) potential for a developer
to modify the data of an AudioBuffer while it is currently playing.  But if
the developer would wait for the .onended handler to be called first, then
he would know it is safe to modify the AudioBuffer PCM data without any
risk of unpredictable results.  So we *are* talking about an order of
execution situation here.

I would say that if we had to focus on any one area where there is the
problem of very true and troubling raciness, then it is the
ScriptProcessorNode.  It will easily be possible to write code using this
node where the .onaudioprocess handler could get called too late on some
browsers or operating systems, resulting in glitches.  I agree that the
value of this node outweighs this risk, but it is very real and likely to
come up.  The so-called "problem" with the AudioBufferSourceNode is
extraordinarily less likely to present any realistic kind of risk.

Chris