Re: New proposal for fixing race conditions

On Thu, Jul 25, 2013 at 9:16 AM, Joseph Berkovitz <joe@noteflight.com>wrote:

> Here's a suggestion that I haven't seen on the list. It may be dismissible
> on its face by those who know more about browser internals, but I believe
> in the power of silly ideas to stimulate discussion. At worst, they are
> just silly.
>
> What if we detected potentially racy modifications to audio buffer data
> after the fact, by examining some sort of quickly calculated digest of the
> buffer (or of relevant blocks of it) in the audio thread and seeing if the
> digest changes between buffer accesses? If it changes, then the bad
> behavior could be flagged via an exception or other notification that would
> deter developers from going live with such applications. This would seem to
> avoid copying overhead and would not change the API.
>

The reason why that will not work is that the race condition may or may not
happen in a given UA on a given machine depending on the workload, which
means if you don't see the race condition in your testing, it doesn't mean
that your code is not relying on it unless you know things about the
implementation and possibly the hardware architecture.

Also, note that calculating this checksum requires looking at every sample,
which is going to result into something that is more costly than a
potential memcpy, which may not even be necessary in the first place.

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>



>    .            .       .    .  . ...Joe
>
> *Joe Berkovitz*
> President
>
> *Noteflight LLC*
> Boston, Mass.
> phone: +1 978 314 6271
>   www.noteflight.com
> "Your music, everywhere"
>
> On Jul 24, 2013, at 6:33 PM, Marcus Geelnard <mage@opera.com> wrote:
>
>
>
>
> On Wed, Jul 24, 2013 at 1:10 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>>
>> An interesting exercise: assume we allow races on AudioBuffer's
>> ArrayBuffer contents, and figure out what the spec needs to say about what
>> is actually played by an AudioBufferSourceNode. I think it's going to be
>> rather complex. (I think this exercise will be useful because I think it
>> will illuminate the differences between nondeterminism due to data races
>> and other kinds of nondeterminism.)
>>
>
> I agree. The specification is very unclear on what behavior one should
> expect from an implementation when it comes to accessing
> (observing/modifying) shared buffer data.
>
> On a related note, I did another simple test app (for testing some aspects
> of shared buffers):
> http://people.opera.com/mage/test/webaudio-mutable-buffers.html
>
> The demo itself isn't that interesting, but if you have a look at the code
> you'll find some fairly odd and implementation-dependent solutions that I
> think are not *that* far fetched (if the API's in the wild, someone will
> come up with similar solutions sooner or later).
>
> What I find especially interesting here (except that you can modify the
> AudioBuffer while it's playing) is that I could get the demo working (in
> Chromium) by caching the double-buffered input/output arrays in the
> ScriptProcessorNode.onaudioprocess event. Sure, you *shouldn't* be coding
> this way, but a mad optimizer might tend to try things like this. In
> particular, this specific solution is *extremely* implementation dependent,
> and will very likely fail on another implementation (even if it doesn't use
> neutering or any other "tricks").
>
> My point is:
>
> 1) *If* we're going to keep the racy buffers, the expected behavior *must*
> be specified in detail. Otherwise it will be impossible to get
> interoperability between different implementations.
>
> 2) It would most likely be *much* simpler to change the interfaces so that
> they are well defined by design (here I think Jer's proposal is much more
> well defined).
>
> /Marcus
>
>
>
>
>