- From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Date: Wed, 31 Jul 2013 18:10:33 -0400
- To: Chris Wilson <cwilso@google.com>
- Cc: Noah Mendelsohn <nrm@arcanedomain.com>, Anne van Kesteren <annevk@annevk.nl>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "robert@ocallahan.org" <robert@ocallahan.org>, Alex Russell <slightlyoff@google.com>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>
- Message-ID: <CANTur_6y+CGeMLEGuc3DUEEBcTTp5rb=tqakBsP=KBXPGgHQ9Q@mail.gmail.com>
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 >>>> >>>> >>> >> >
Received on Wednesday, 31 July 2013 22:11:40 UTC