Races - how bad?

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. 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. 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.

I am not using this to argue for one proposal or another -- simply trying to cast some light on the situation for developers and end users, the people we're trying to protect.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"