Re: Races - how bad?

On Thu, Aug 1, 2013 at 9:42 AM, Joseph Berkovitz <joe@noteflight.com> wrote:

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

As I've stated before <
http://lists.w3.org/Archives/Public/public-audio/2013JulSep/0234.html>,
there are two problems that we're dealing with here.  I don't think anybody
has argued that we're trying to build a fully deterministic API.  Almost
all of the hugely successful computing systems I can think of have inherent
non-determinism in them from the perspective of one application running on
that platform.  Reading/writing data without any synchronization from
multiple threads is a different kind of problem.

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