Re: TAG feedback on Web Audio

That document is a bit misleading/outdated when it comes to data races
being "harmless". This more recent article illustrates these issues:
http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong


Adam


On Wed, Jul 31, 2013 at 6:17 PM, Chris Wilson <cwilso@google.com> wrote:

> Indeed, that's the kind of context elaboration I was suggesting.
>
>
> On Wed, Jul 31, 2013 at 3:10 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>
>> On Wed, Jul 31, 2013 at 6:04 PM, Chris Wilson <cwilso@google.com> wrote:
>>
>>> I'm just saying "race condition" is a general term for a situation where
>>> output is dependent on the sequence or timing of other events.  Racing is
>>> inherent in an async platform with entropy in it; that doesn't make it bad.
>>>  If this is explicitly about multithreaded unsynchronized data variable
>>> access, that should be stated.
>>>
>>
>> Race conditions and data races are different although there is an
>> overlap.  Please see <http://blog.regehr.org/archives/490>.  I know that
>> this terminology has caused massive confusion in this thread, and I'm sorry
>> about that, but unfortunately I can't think of better terminology here.  :/
>>
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>>
>>
>>
>>
>>> On Wed, Jul 31, 2013 at 2:45 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>>
>>>> On Wed, Jul 31, 2013 at 1:43 PM, Chris Wilson <cwilso@google.com>wrote:
>>>>
>>>>> In addition, I'd ask that you be more explicit than calling this
>>>>> problem "data races", because there's clearly some explicit effect you're
>>>>> trying to prevent.  Any asynchronously-programmable or event-driven system
>>>>> can enable developers to introduce race conditions.
>>>>>
>>>>
>>>> This problem is known as data races in the common multi-threaded
>>>> terminology, but I'm personally not attached to that name, whatever other
>>>> name which conveys what we mean is fine.  :-)
>>>>
>>>>
>>>> --
>>>> Ehsan
>>>> <http://ehsanakhgari.org/>
>>>>
>>>>
>>>>
>>>>> On Mon, Jul 29, 2013 at 10:09 PM, Noah Mendelsohn <
>>>>> nrm@arcanedomain.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/29/2013 7:05 PM, Anne van Kesteren wrote:
>>>>>>
>>>>>>> On Sat, Jul 27, 2013 at 9:22 AM, Noah Mendelsohn<
>>>>>>> nrm@arcanedomain.com>  wrote:
>>>>>>>
>>>>>>>> >Again, I have no informed opinions on the specific merits, just
>>>>>>>> suggesting a
>>>>>>>> >useful role the TAG might play to clarify for the many members of
>>>>>>>> the
>>>>>>>> >community who are less expert on this than you are. Thank you.
>>>>>>>>
>>>>>>>
>>>>>>  I'm not sure we call out data races anywhere, it's something we just
>>>>>>> don't do.
>>>>>>>
>>>>>>
>>>>>> Well, my recollection may be faulty, but I think that one of the
>>>>>> reasons the TAG took the trouble to formalize things like the architecture
>>>>>> document was the belief that it's easier to ask skeptics to stick to rules
>>>>>> that have been written down, and especially those that have garnered formal
>>>>>> consensus through something like the Recommendation track.
>>>>>>
>>>>>> Whether it's worth taking a guideline on data races all the way to
>>>>>> Rec I'm not sure, but it seems that it would be worth setting it down
>>>>>> formally, perhaps in a TAG Finding/blog post/Recommendation or whatever
>>>>>> will get the right level of discussion, consensus building, and eventually
>>>>>> attention.
>>>>>>
>>>>>> Certainly, of the many things that have come up recently relating to
>>>>>> APIs, this one seems deeply architectural and very much within the TAG's
>>>>>> remit.
>>>>>>
>>>>>> Noah
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>