Talk:Race condition

Ajax Example

That Ajax race condition example makes no sense to me since Ajax runs on top of HTTP and HTTP runs on top o TCP and TCP assures that the packets will be delivered in order. xissburg 18:10, 13 June 2010 (UTC) —Preceding unsigned comment added by Xissburg (talk • contribs)

Moved

I moved this page from race hazard by copying. Sorry if that is the wrong way to do it -- I couldn't just rename "race hazard" because "race condition" already linked the other way. Perhaps I could have renamed "race condition" to something else first; but that seems questionable and still might not have worked.

See Talk:Race hazard. Benwing 01:11, 12 August 2006 (UTC)

Is cleanup necessary?

This page has carried the cleanup tag since April 2006. What's wrong with it? In what specific way or ways does it fail to meet Wikipedia's quality standards? Unless this last question receives a suitable answer by the end of October 2006, I propose to remove the cleanup tag. yoyo 13:12, 25 September 2006 (UTC)

I did not put the tag on, but here's a few reasons I think it should stay:

• I think the computer science version deserves its own article. It could be bulked out a lot more. This is a major topic in software. This page just gives a cursory overview of the problem, with almost nothing about how to avoid it. The links to synchronization and concurrency control are not integrated into the text, and there's no mention of communicating sequential processes.
• It's largely unreferenced. A few good references might mitigate the lack of content.
• The "real life examples" section is poorly organized. It mixes together a vague mention of techniques to avoid filesystem race conditions (without describing the actual problem there), theoretical examples in different problem domains, and descriptions of their negative effects. None in any real detail.
• The terminology isn't consistent - some leftover "race hazards".
• What is that "Asynchronous Finite State Machines" section doing down there? Its one paragraph is obviously missing context. I think it came from the electronics section.

In fact, the only part of this page I like is the first paragraph. -Slamb 06:21, 26 September 2006 (UTC)

Regarding the split you meantioned: this article was originally called "race hazard", and was later moved to "race condition" as the latter term is almost universal when it comes to computer software. If the term "race hazard" is used for referring to this in electronics, then I suppose the electronics-specific meaning can simply be moved back to "race hazard". -- intgr 12:10, 6 December 2006 (UTC)

Race conditions in hardware and software are essentially the same thing. There's no need for there to be two separate pages. The discussion of hardware is also relevant to simulated hardware, such as ladder logic programs. --DavidHopwood 23:17, 28 August 2007 (UTC)

No. They are not. What is described in the hardware section would be called a data race (see the following section) by a software developer. In software hazards are no race conditions. --Fabiwanne (talk) 11:36, 19 May 2015 (UTC)

The term "Race Condition" describes one particular problem. This problem occurs whenever the state change of something (hardware, software, system) is shared between two or more actors. Currently the hardware description is excellent, but the software/system description is, at best, misleading. The underlying problem is the need for guaranteed mutual exclusion between the actors. A "Race Condition" occurs when two or more actors don't know who won the race to acquire the shared resource first. When the actors are hardware signals, the solution requires hardware to resolve the dispute. When the actors are software processes or systems, the solution requires software (and possibly hardware) to resolve the dispute. With software processes or systems determining who has won the 'Race' is done by creating 'mutual exclusion' around the finish line (shared recourse). So for software processes and systems, 'Race Condition' means mutual exclusion is needed to determine which actor was the first to acquire the shared resource. All other actors must be forced to wait for the resource, or told they were not the first to get it. Beyond connecting the name of this situation with a particular case of the need for mutual exclusion, this situation is just one of many that are solved using an appropriate form of mutual exclusion. Stan Osborne (talk) 18:59, 17 January 2009 (UTC)

Even the hardware section needs to be re-written. The example used in the lead image is entirely predictable, with some electrical designs intentionally doing this in a variety applications where pulses and glitches are involved. It is not a true example of a race condition. The last time I proposed re-working the article (but was shot down) I suggested an example, such as an electrical engineer is designing an elevator control circuit and someone pushes the up button at the same time as somebody else pushes the down button. The example could show the absurdly poorly designed system's worst case scenario, the elevator catches fire because both the forward and reverse power is applied to the motor at the same time, causing the motor to burn up. However the engineer eventually solves the problem by adding a state machine to arbitrate weather the elevator goes up first or down first. As the example proceeds it could get more technical such as the state machine does not handle the case where control signals for master flip-flop change at essentially the same time as the system clock. Finally the engineer adds an override switch to the motor power supply switches that functions separately from the main system, just in case anything was missed.

I know this is overly simplistic example for an engineer, but the goal of an encyclopedia _SHOULD_ be to explain a concept to a general audience for the purpose of learning, not to people who are already experts in the field. This article has several other issues including violations of numerous sections of the WP:MOS. One statement that really needs to be fixed is the misspelled statement that K-maps eliminate race conditions. They do not, K-maps is a method to optimize system logic to reduce the number of steps where race conditions can occur, but will not eliminate them entirely.Dave (talk) 20:49, 17 January 2009 (UTC)

I agree that the example given is not a proper race condition, but a proper one would be difficult to illustrate, since it is a system that's coupled in at least two places to a black box. On the other hand, this improper race condition is splendidly simple and easy to understand, so perhaps it should be labeled as a simulation of a race condition. AngusCA (talk) 17:59, 15 May 2009 (UTC)

Race conditions between systems

I added content to the introduction to mention that race conditions can occur between systems (particularly control systems). It has since been reverted. But I contend my additions are correct. Race conditions can and do occur between systems and is something I deal with frequently in my profession. It was reverted with the reason given of being misleading, please explain? What is misleading about that? Is it the consensus that Race conditions only occur within a single system and "race conditions" between systems are something else? Davemeistermoab 14:57, 28 March 2007 (UTC)

Race condition occurs on signals. Signals interconnect systems, so, strictly speaking, race conditions always occur between systems or sub-systems. Since there was no definition of system or sub-system, this section is superfluous and redundant. Anyhow, IMHO, special attention to control systems, if needed, should be placed in a specific section of the article, not in the introduction, which should be as generic as possible. With utmost respect, Michagal 16:02, 28 March 2007 (UTC).

I do see your point, and partially agree. However, that still means the introduction needs improvement. System is still undefined, and equally as misleading. Nowhere in the article as presently worded is the statement that race conditions occur between systems. The article in its present state implies the opposite of your above statement. I also don't see how my changes made the introduction only apply to control system rather than the general definaton of race condition. In fact, I think it made it more inclusive.

Second, the statement that all race conditions come from design defect is not true. There are times where race condition situations are knowingly placed or left in a system because the probability or consequence of them occuring makes them less risky than addressing them. For example, suppose in the automobile there is a potential race condition in the mechanical linkages. The best fix would be to break the mechanical linkage between the brake pedal and the master cylender and make this connection electrically, where a state machine or other form of abritration is easier to impliment. Race condition is fixed, but doing so introduces failure modes in the brake system far worse and far more likely to occur than the race condition (i.e. you lose electrical power, you loose brakes amongst many others). Better to leave the race condition in for safety reasons, not because of a poor design or defect.

I am willing to help on revising the article. I think the examples are much too complicated for a general audience. They are fine as follow on examples, but the first example should be one that non-techies could relate to. I would say an example involving the "push to cross" buttons on a traffic signal or elevator control module (open door and close door buttons are pressed at the same time)or something.

Davemeistermoab 03:09, 29 March 2007 (UTC)

I feel that the introduction is optimal as it is now, with a possible change to potential flaw to exclude systems that work well with races, such as synchronous digital circuits. I wish to remind that the definition of the term should equally apply to electronics, control systems and software.

Examples made by you are extremely important and helpful and a section should be added with control systems/mechanical systems examples.

As for the implied notion that all race condition come from design flaws, your argument does not sound convincing. If a potentially malicious condition is left in the design as it would be too difficult or risky to repair, it is still a design flaw. Michagal 07:42, 29 March 2007 (UTC)

I think at this point it would be best to wait for someone else to chime in and see if we can get some concesus. I think at this point we both respect each other but disagree, so maybe wait and see what others think. If i'm declaired to be a nut with my take on this topic, so be it =-) Davemeistermoab 05:15, 30 March 2007 (UTC)

In my opinion, race conditions can be part of well-designed systems where they are worked around. For example, the IP protocol does not guarantee in-order delivery of packets — a packet sent earlier may be received later by the destination host — it depends on timing, and hence is something I would consider a race condition. Nobody says the IP protocol is flawed for this reason; higher level protocols simply have to deal with it, or be ordering-agnostic.

That said, I am pretty ignorant about the academic take on this subject, so my definition may be misled. The definition given by this article is rather vague; what does "unexpectedly and critically" mean? Whether a person expects the race condition or not is up to their competence. -- intgr 15:54, 30 March 2007 (UTC)

Intgr, I would say that the packet sequencing of the IP protocol is an excellent example of one way to resolve a potential race condition. As this page is currently defines the term, TCP/IP would not be a race condition because the page implies you need 2 signals. But I agree the concept of a race condition is bigger than the current article allows. I don't think the academic take much matters. Wikipedia is an encyclopedia "of the people, by the people, for the people" if someone wants the academic take they can check the encyclopedia Britannica =-). With that said, what do you think the introduction to this article should say? You can see my opinion on this subject by seeing the history and the changes I attempted to make. Judging from the tag, i'm not the only one who thinks this article needs some work. So what _should_ this article say?

----

I agree with Intgr. It makes no sense to me that a race condition must be unexpected. This implies that once it becomes expected it ceases to be. It also implies that one cannot specifically design something to contain a race condition, which would render useless the various examples given. -- Siggimoo (talk) 21:31, 17 November 2010 (UTC)

While I might agree with your logic, that it should mean something different, this is not what really matters for Wikipedia (it would be WP:OR). What matters is that it really means as understood by majority, and personally I have no doubt that race condition is always used in the context of bug, therefore this logic doesn't fly for Wikipedia article. If you can provide reliable references to somebody using race condition to describe useful things, it would be a different story. Ipsign (talk) 06:10, 18 November 2010 (UTC)

In that case, I think unintended would be a better choice of word. -- Siggimoo (talk) 22:29, 28 November 2010 (UTC)

I agree generally with the above discussion, but would like to add a couple of points: First, early in this article a claim was made that the term "race condition" was coined in a 1969 paper (no citation given). My (usually accurate) memory reminds me of a discussion I had with fellow avionics engineers in 1966 at Vought Aeronautics in Dallas, in which the term came up (with the same meaning). We were dealing with the complex logic of a redundant flight control system, in which race conditions could be extremely hazardous. Second, I would suggest that a "race condition" occurs when a system thought (or intended) to be deterministic exhibits non-deterministic behavior.TPOBrien (talk) 21:00, 6 January 2018 (UTC)

Body Count for Therac-25 Incident?

The paragraph in this article concerning the Therac-25 incident says that the body count was three dead people; however the article at http://www.wired.com/software/coolapps/news/2005/11/69355?currentPage=1 says that the total body count was "at least five". Which is correct? tharkun860 (talk) 15:33, 18 June 2009 (UTC)

Difficult to say, there is a difference in opinions, but about three there is more or less a consensus. Ipsign (talk) 05:59, 18 November 2010 (UTC)

Therac-25 not a race condition?

Talk:Therac-25#Not_a_.22race_condition..22 asserts that the Therac-25 incidents were not caused by race conditions. I'll leave this to someone familiar with the issues. Karl gregory jones (talk) 20:43, 14 October 2009 (UTC)

See reply of 24.16.76.175 there, it is race condition; I've studied this case personally in some detail and I agree it is a race condition (while race condition was not the only flaw which lead to deaths, but without race condition there likely won't be any); to start with, for the problem to manifest itself, operators should have done certain operations within 8 seconds, which itself is a strong indication for race condition; also it contributed to the fact that the problem started to occur only after operators get experienced, and therefore has never been found in tests. Ipsign (talk) 06:05, 18 November 2010 (UTC)

Data race != race condition

This article should distinguish between a data race and a race condition. See: http://blog.regehr.org/archives/490 — Preceding unsigned comment added by Krainert (talk • contribs) 11:39, 19 September 2011 (UTC)

Find a reliable source. --Walter Görlitz (talk) 13:57, 19 September 2011 (UTC)

Magee & Kramer — Preceding unsigned comment added by 130.225.0.251 (talk) 12:37, 22 September 2011 (UTC)

This is a post from John Regehr, a professor of computer science in University of Utah. I can't see how can this not be a reliable source. OriumX (talk) 19:12, 29 November 2012 (UTC)

@Bin927 and Madanmus: You are in disagreement on this issue, please discuss. -- intgr [talk] 08:06, 31 March 2015 (UTC)

The problem is that "Data race != race condition" is true for Software but not for hardware. In fact this article describes two similar, but in fact different things with the same name. Splitting the article into two would solve the problem. --Fabiwanne (talk) 11:44, 19 May 2015 (UTC)

And so we're back to the original request to provide a reliable source to support. Walter Görlitz (talk) 14:11, 19 May 2015 (UTC)

Give me a source that elephants and cars are not the same. If not, I join the articles... If you read (and understand) both section it's absolute obvious that there is a difference. (Just look at the example circuit and search where "the end result is nondeterministic".) But no one will waste dead trees (= reliable source?) to write books how things are not. (Especially because there are indefinite ways ow thing are not.) --Fabiwanne (talk) 20:01, 19 May 2015 (UTC)

I have no doubt that data races are not equivalent to race conditions.

Furthermore, I think there is a burden of proof issue here; when one is presented with two different terms, they must be assumed distinct unless evidence can be provided that they are equivalent. So, it is those who think that these terms are equivalent who must provide proof (which they will not be able to do, because the terms are not equivalent).

"Data race" is defined differently in various formal models, however, I have never seen a definition of data race that defines it as equivalent to "behavior...dependent on the sequence or timing of other uncontrollable events". I have only seen data races defined as pairs of computer memory operations that are in some sense simultaneous or unordered, and one of them is a write. Usually the sense in which they are unordered is further defined in a very specific manner (e.g. at least one of them is non-atomic and the given happens-before partial order does not order them). Such a definition cannot be equivalent to race condition because programs without data races can still have race conditions. In fact this is probably the motivation for calling them data races; various SC for DRF papers categorize memory operations into data operations vs synchronization (or 'special') operations. The premises of these theorems permit races on the sync operations but not on the data operations. I don't know if you will find a published paper specifically discussing the fact that 'data race' and 'race condition' are not synonymous because this is trivially obvious once the term 'data race' is defined formally.

Some of the comments above suggest that there is a distinct notion of "data race" in hardware? I am just talking about software here. However, if the terms are distinct in the context of software but not in the context of hardware, then the terms are nonetheless not equivalent overall. For two formal terms to be equal, they must be equal in every instance; a single instance in which they are not equal is enough to disprove equality in general.

Bayle Shanks (talk) 16:12, 26 July 2019 (UTC)

If you want to create sub-classes, go ahead, but they're still a sub-class of a race condition. Walter Görlitz (talk) 16:34, 26 July 2019 (UTC)

Data race as subsection vs separate page

In my opinion there is a lot to be said about data races. Furthermore, at least one computer science professor believes that "data race" is not a subtype of "race condition" but is a disjoint concept. Therefore in my opinion the material on data races should be moved to a separate page. Bayle Shanks (talk) 16:25, 26 July 2019 (UTC)

Exact wording of article found in book

Hi everyone,

Just passing by and found the exact same wording of some of the examples in the article in a book found here:

https://books.google.com/books?id=qb0QBwAAQBAJ&pg=PA507&lpg=PA507&dq=first+energy+blackout+race+condition&source=bl&ots=VBFnRXAIXX&sig=iMWLV74l-ohNZTzRYq10jCuo7z0&hl=en&sa=X&ei=bdk9VfSTBI_haMPCgLAO&ved=0CEwQ6AEwBg#v=onepage&q=first%20energy%20blackout%20race%20condition&f=false

Not sure whether the article is copied from the book or the book is copied from the article, but worth investigation nonetheless. — Preceding unsigned comment added by 128.12.18.132 (talk) 06:48, 27 April 2015 (UTC)

Good detective work.

The copy in the book and the article clearly overlap in several sections.

The book is a "Print on Demand (Paperback)" and I found no copyright date for it, http://www.amazon.ca/Security-Threats-High-Impact-Strategies-Definitions/dp/1743045794 so it's not clear when that book was first published. Than means we have to do some detective work.

File systems section went in 2006-12-27 07:52:00 and was added by Parsiferon https://wiki.riteme.site/w/index.php?title=Race_condition&diff=96705985&oldid=96700866

Networking section went in 2005-06-02 00:39:59 and was added by 80.177.120.17 https://wiki.riteme.site/w/index.php?title=Race_condition&diff=14680545&oldid=14556059 That section was changed recently and no longer resembles the book

Life-critical systems I can't find where this went in, but it was in-place 2006-08-08 17:09:08 https://wiki.riteme.site/w/index.php?title=Race_condition&oldid=68433374

The Computer Security section went in 2005-09-12 06:45:57 and was added by Quarl https://wiki.riteme.site/w/index.php?title=Race_condition&diff=23087241&oldid=22901945

So my conclusion is that the sections were added here over an eighteen-month period and were added by multiple editors. If what we had was a copy from that book, I would expect a larger deposit of material, in a shorter period of time, and with one, or at most, two editors. That's not the case. It appears as though the author lifted the material from here. I cannot see if the author attributed Wikipedia or not. Walter Görlitz (talk) 07:39, 27 April 2015 (UTC)

File System Examples

I don't believe the examples cited in the filesystem examples are race conditions. They're example of [Resource Contention]. They're actually examples worth moving to that page, as there aren't any there. But they should be cut here out of causing confusion as to what a data race condition in an FS is. SteveLoughran (talk) 14:54, 26 May 2016 (UTC)

Reference 6 is circular reference

Reference 6 ("How Brains Race to Cancel Errant Movements". Discover Magazine blogs. 2013-08-03.) has a direct link back to the wikipedia article so I believe should be removed. — Preceding unsigned comment added by 217.140.96.140 (talk) 16:40, 25 April 2017 (UTC)

It's not the definition of a circular link. It may reference Wikipedia, but it's not a copy of it. Walter Görlitz (talk) 18:10, 25 April 2017 (UTC)

Why does it not meet the definition of a circular reference? Each article contains a reference to the other. Furthermore, reference 7 appears to be the source material for the content of reference 6 (indeed, reference 6 references reference 7). This gives the appearance of 2 sources when really there is only 1. — Preceding unsigned comment added by 217.140.96.140 (talk) 13:40, 27 April 2017 (UTC)

If there are two sources that are one, that's a different issue. Simply because a source references this article does not mean that the external source relied on Wikipedia for that fact. Cause and effect has not been shown. Walter Görlitz (talk) 14:33, 27 April 2017 (UTC)

True, they are not each claiming the other as the source - so it is not a circular reference. So it is now only the issue of there being only one true source. 217.140.96.140 (talk) 11:10, 28 April 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Race condition. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070926215258/http://chiralsoftware.com/blog/Race-condition-vulnerability-in-syscall-wrappers-fa3e57c594119803.html to http://chiralsoftware.com/blog/Race-condition-vulnerability-in-syscall-wrappers-fa3e57c594119803.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:26, 11 December 2017 (UTC)

"Critical" race condition in C++

The article states:

The memory model defined in the C11 and C++11 standards uses the term "data race" for a critical race condition caused by concurrent reads and writes of a shared memory location.

where "critical" is previously defined as:

A critical race condition occurs when the order in which internal variables are changed determines the eventual state that the state machine will end up in.

However, the C++ memory model is very weak and makes no such distinction. From [intro.races/20] (N4659):

Two actions are potentially concurrent if they are performed by different threads, or they are unsequenced, at least one is performed by a signal handler, and they are not both performed by the same signal handler invocation.

The execution of a program contains a data race if it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below. Any such data race results in undefined behavior.

(By the way, there is generally no "order" of potentially concurrent operations in C++, unless otherwise specified.) I will therefore remove the word "critical" from this context. Aragorn2 (talk) 19:41, 8 February 2018 (UTC)

Origin of the term "race condition"

The uncited origin of the term "race condition" in 1969 seems dubious, since it is used in a paper by D.A. Huffman in 1954, Research Laboratory of Electronics, Massachusetts Institute of Technology — Preceding unsigned comment added by 80.146.191.220 (talk) 11:15, 3 September 2018 (UTC)

Feel free to be WP:BOLD and remove the unreferenced statement and state something to the effect that the origin of the term is unknown but that it was in the paper. Be sure to cite the page number of the paper. Provide a quote if possible. Also, be careful not to claim that it is the earliest-known version since we don't know it is the earliest. Walter Görlitz (talk) 17:06, 3 September 2018 (UTC)

Merge into Hazard (logic)

Merging Race_condition into Hazard (logic) should be considered. Or maybe one should be for software and the other for hardware? 213.149.61.226 (talk) 21:57, 28 October 2018 (UTC)

You want to move a large article into a small one for what reason? Walter Görlitz (talk) 05:33, 29 October 2018 (UTC)

Very, very late comment. Races don't necessarily cause hazard or anything undesirable. Races can be deliberate, essential to device function as in dynamic MOS logic (think of early digital watches). In such logic, "uncontrollable events..." mentioned in the lead are, in fact, controllable and predictable by design. Retired electrician (talk) 19:02, 15 September 2020 (UTC)

Okay so what is really the difference between the race condition shown in the figure with the AND gate and a static hazard? Exactly the same circuit is taught as static hazard, eg. here http://www.doe.carleton.ca/~shams/ELEC3500/hazards.pdf . Now we have to wiki articles which use different names for the same thing and don't even mention it. It's clearly in need of refreshment. Of course the other article (hazard as mentioned above) is a bad quality article now, copied from some website without the images. Hoemaco (talk) 11:28, 6 April 2021 (UTC)

User interfaces

Is there a name for when, right before you type or click, the state of the UI changes (a window appears, for example a file selection dialog in Firefox, or a different web page loads), making you click the wrong thing? --AVRS (talk) 21:18, 16 May 2019 (UTC)

@AVRS: Does this have anything to do with improving or modifying the article or are you hoping to get help for an unrelated activity? Walter Görlitz (talk) 21:36, 16 May 2019 (UTC)

@Walter Görlitz: I thought it was a race condition, but found nothing about it in this article, not even under "See also". --AVRS (talk) 23:47, 16 May 2019 (UTC)

@Walter Görlitz: Whatever @AVRS:'s motivation, I find his question relevant, and think it sounds like a race condition in the user interface, even if it would not normally be so described. It is after all a genuine recognisable error (the system does not behave as it was, one hopes, intended) caused by uncontrollable relative timing of two parallel processes, one including the user + input devices, and the other the display processes. PJTraill (talk) 13:50, 27 May 2019 (UTC)