Talk:Race condition

From Wikipedia, the free encyclopedia

[edit] 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)

[edit] 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)

[edit] 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?