Re: Races - how bad?

On Aug 1, 2013, at 8:21 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
> Obviously, even with those restrictions it's still necessarily nondeterministic when each batch of operations is applied relative to the progress of the audio thread. There's really no way around that; it's a minimum amount of nondeterminism that we just have to live with.

That's exactly what I believe too -- and I'm glad you said it, because I wanted to call out this point clearly.

Furthermore, the point at which a disconnect() takes effect has AFAICT no deterministic time offset in the output stream at which the node ceases to contribute. It's a matter of when the audio thread happens to process the disconnect operation.

Consequently we are not, as some have claimed, comparing a nondeterministic approach (shared memory) with fully deterministic alternatives. There is a residual "zero-point nondeterminism" that remains after all is said and done. And this nondeterminism is manifested as uncertain output at the sample-frame level, not with respect to some set of coarse-grained atomic operations in the API on audio content.

I don't have any problem with this behavior, and have no expectation that we can eradicate this bit of nondeterminism. Neither am I denying that the overall gain in determinism from the non-shared-memory approaches has a tangible value. I'm simply pointing out that we should be wary of believing that these changes would take us to a fully deterministic API. They simply reduce the set of risky edge conditions, in particular those where a developer unwittingly modifies data in advance of its consumption by a node that has been scheduled to become active and has never been disconnected. Residual timing-dependent uncertainties remain.

…Joe

Received on Thursday, 1 August 2013 13:42:36 UTC