Re: Races - how bad?

Thanks for writing this up, Joe!

On Wed, Jul 31, 2013 at 2:09 PM, Joseph Berkovitz <joe@noteflight.com>wrote:

> Hi all,
>
> I think it may be useful to try and briefly answer a challenge that
> Olivier posed a while ago -- to evaluate the current data race potential in
> terms of the question, "How bad is this?" as opposed to "How costly in
> terms of performance?" or "How complex for developers and
> implementors?" The very thoughtful proposals that have been floated to fix
> data races still leave room for a great deal of unpredictability in browser
> behavior, even though they ameliorate it. Everyone has already done a great
> job of talking about "how costly?" or "how complex?".  "How bad?" hasn't
> received nearly the same amount of attention.
>
> As others have said already, we should be looking at the *incremental*
> unpredictability of shared memory behavior relative to the alternatives,
> rather than speaking as though there is predictability under one approach
> and none under another. To me, statements like "audio API data races are
> inadmissible" or "audio API data races are not that bad" fail to articulate
> the actual downside of one approach vs. another for developers and end
> users.
>
> Under all proposals, there are opportunities for the main thread to at
> least attempt the modification of objects that could be in active use by
> the audio thread.
>

How do you mean?


> Let's call this "risky behavior" by developers. Given risky behavior,
> concurrent access might or might not happen, depending on browser choice,
> device platform, or ambient runtime conditions. And let's take it as a
> given that people will engage in it, knowingly or otherwise.
>
> I'd like to try to make a comparative statement that describes *how much
> worse is risky behavior* with shared memory as opposed to the alternatives,
> in terms of both the actual audio output and error detection. Here is an
> attempt, probably inadequate, but I feel it's worth trying. I'm sure others
> can improve it.
>
> -- With shared memory, risky behavior may allow partial computation
> results or or partial buffer contents to be unexpectedly used by the audio
> thread for rendering purposes. The results will be degraded, glitchy or
> absent audio output. There is no runtime error available to either the
> developer or end user if this takes place.
>
> -- With the alternative proposals (e.g. ROC, Jer, Chris W), risky behavior
> may unexpectedly throw an exception due to accessing a neutered data
> structure or [Jer] by modifying an active buffer channel.
>

I don't believe that is accurate.  With these proposals, the risky behavior
will unconditionally throw an exception.  Which is a definite advantage
over a non-detectable runtime error that you may or may not hit when you're
testing your application.


> Runtime errors *may* signal the developer that this has taken place, if
> the exception is caught. In that case they may cause the end user to become
> aware of an application problem even if the developer never saw it. But if
> the errors are uncaught by the developer, the end user's likely perception
> is the same as above: degraded, glitchy or absent audio output.
>

These exceptions not being handled is basically as bad as any other
unhandled exception in the web platform, and the results may vary from
breakages that are not evident to the end user to complete malfunctioning
of the system, depending on what code the exception skips when it's raised.

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