COMP 3000 Essay 1 2010 Question 6 - Revision history

Soma: Unprotected "COMP 3000 Essay 1 2010 Question 6"

2010-11-08T15:33:35Z

Unprotected "COMP 3000 Essay 1 2010 Question 6"

← Older revision	Revision as of 15:33, 8 November 2010
(No difference)

Soma: Protected "COMP 3000 Essay 1 2010 Question 6" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-10-15T13:35:28Z

Protected "COMP 3000 Essay 1 2010 Question 6" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 13:35, 15 October 2010
(No difference)

Cha0s: /* Conclusion */

2010-10-15T10:53:37Z

Conclusion

← Older revision		Revision as of 10:53, 15 October 2010
Line 118:		Line 118:
	=Conclusion=		=Conclusion=

	Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any ~~real world~~ system ~~is capable of experiencing~~ a race condition, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical and essential systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.		Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any system could have a race condition bug, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical and essential systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.

	=References=		=References=

Cha0s at 10:39, 15 October 2010

2010-10-15T10:39:25Z

Show changes

Cha0s: /* References */

2010-10-15T10:19:49Z

References

← Older revision		Revision as of 10:19, 15 October 2010
Line 128:		Line 128:
	* Nancy Leveson and Clark Turner. July 1993. [http://www.stanford.edu/class/cs240/readings/therac-25.pdf An Investigation of the Therac-25 Accidents]		* Nancy Leveson and Clark Turner. July 1993. [http://www.stanford.edu/class/cs240/readings/therac-25.pdf An Investigation of the Therac-25 Accidents]
	* Anne Marie Porrello. July 1993. [http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html Death and Denial: The Failure of the THERAC-25, A Medical Linear Accelerator]		* Anne Marie Porrello. July 1993. [http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/THERAC25.html Death and Denial: The Failure of the THERAC-25, A Medical Linear Accelerator]
	* Kevin Poulsen. April 2004. [http://www.securityfocus.com/news/8412]		* Tracking the blackout bug. Kevin Poulsen. April 2004. [http://www.securityfocus.com/news/8412]
	* JR Minkel. August 2008. [http://www.scientificamerican.com/article.cfm?id=2003-blackout-five-years-later]		* The 2003 Northeast Blackout - 5 Years Later. JR Minkel. August 2008. [http://www.scientificamerican.com/article.cfm?id=2003-blackout-five-years-later]
	* Final Report on the August 14th Blackout in the United States and Canada. US-Canada Power System Outage Task Force. [https://reports.energy.gov/]		* Final Report on the August 14th Blackout in the United States and Canada. US-Canada Power System Outage Task Force. [https://reports.energy.gov/]
	* Reliability Standards. North American Electric Reliability Corporation. [http://www.nerc.com/page.php?cid=2\|20]		* Reliability Standards. North American Electric Reliability Corporation. [http://www.nerc.com/page.php?cid=2\|20]

Cha0s at 10:16, 15 October 2010

2010-10-15T10:16:07Z

← Older revision		Revision as of 10:16, 15 October 2010
Line 7:		Line 7:
	=Overview=		=Overview=

	A race condition occurs when two or more processes receive write access to shared data simultaneously. The end result ~~might lead~~ to unpredictable results depending on the exact timing of those processes. Consequently a major system failure can occur.		A race condition occurs when two or more processes receive write access to shared data simultaneously. The end result leads to unpredictable results depending on the exact timing of those processes. Consequently a major system failure can occur.

	=Introduction=		=Introduction=
Line 13:		Line 13:
	Race conditions are notorious in the history of software bugs. Examples range from a section of Java code causing an application to halt, the corruption of web services, to the failure of a life-critical system with fatal consequences. All of the system failures due to race conditions have common patterns and are caused by inadequate management of shared memory.		Race conditions are notorious in the history of software bugs. Examples range from a section of Java code causing an application to halt, the corruption of web services, to the failure of a life-critical system with fatal consequences. All of the system failures due to race conditions have common patterns and are caused by inadequate management of shared memory.

	During development of ~~these systems~~, programmers ~~do not realize that their designs incorporate~~ a race condition until they occur. They are unexpected, infrequent, and the specific failure conditions are difficult to duplicate. Therefore the origin of the failure ~~may take weeks up~~ to ~~years to discover~~. This is ~~also dependent on~~ the ~~complexity of~~ the ~~system. A lack~~ of ~~testing before deployment may also be responsible. Race conditions usually occur when using~~ code from an older system. The ~~legacy code worked in~~ the ~~previous set up, so it~~ is ~~assumed to work~~ in the ~~new set up as well. This however,~~ is ~~not the case, as many timing issues arise in~~ the ~~new~~ system ~~that the legacy code does not account for~~, ~~as well as~~ the ~~fact~~ that ~~the new~~ system ~~may not have the proper hardware~~ that ~~the older system did.~~		During development of a system, the programmers may have no way of knowing a race condition exists until they occur. They are unexpected, infrequent, and the specific failure conditions are difficult to duplicate. Therefore, it may take weeks or even years for the origin of the failure to be discovered. This is especially true for complex systems. In the following examples, different situations in which race conditions have occurred will be discussed. The Therac-25 race condition shows that the implementation of code from an older system could have fatal results. The 2003 Black-out race condition highlights the need for testing when a system is implemented in a different environment. The Mars-Rover race condition shows the importance of testing of every possible combination of events when it is essential the system never fails. Finally, the BSoD race condition section shows that even a major system that has been implemented in millions of computers can still contain deeply embedded bugs not yet fixed.

	~~Race conditions occasionally reoccur~~ in ~~the same software. An example~~ of this is when the race condition is mistaken as another problem. Another example is when a system contains multiple race conditions. Programming languages where memory management is an important aspect of development, such as Assembly and C/C++, are also common to all of the systems.

	In this article, we will examine the most well-known cases involving race conditions. For each of the cases we will explain why the race condition occurred, its significance, and the aftermath of the failure.		In this article, we will examine the most well-known cases involving race conditions. For each of the cases we will explain why the race condition occurred, its significance, and the aftermath of the failure.

Cha0s: /* Windows Blue-Screens-Of-Death */

2010-10-15T10:04:17Z

Windows Blue-Screens-Of-Death

← Older revision		Revision as of 10:04, 15 October 2010
Line 116:		Line 116:

	==Windows Blue-Screens-Of-Death==		==Windows Blue-Screens-Of-Death==
			When a problem in Windows forces the operating system to fail, the computer will often display an error screen, officially known as a "Stop Error". The message displays what exactly went wrong in white font to a blue background. Because of the color scheme chosen, this screen as received the title "Blue Screen of Death" or BSoD in short. While BSoDs cover a much wider range of errors than simply race conditions, it is one of the more prominent errors.

	~~When a problem in Windows forces the operation systems to fail, the computer often displays an~~ error ~~screen~~, ~~know as Stop message~~, ~~that describes~~ the ~~cause of the problem, most people called this a Blue Screen of Death (BSOD)~~.		The error 0x0000001a, MEMORY_MANAGEMENT, occurs due to a race condition involving memory management on the system.

	The error 0X0000001a, MEMORY_MANAGEMENT, occurs because of the race condition of memory management. It is a hardware error related to memory management. It is possible that the computer can not timely get enough power to the memory for the process.		BSoDs have been experienced by almost anyone who has used OS's like XP or Vista. There have also been more critical systems, such as airports and ATM machines that have also experienced such errors. A particularly public demonstration of the BSoD in action took place at the 2008 Beijing Summer Olympics in China, where one of the projectors crashed during the opening ceremonies.

	~~The BSOD~~ has ~~surfaced on a number of Windows versions including Windows 7~~. ~~It has~~ also ~~caused system failures in~~ airports, ATM machines ~~and street hoardings~~. ~~However, the most notable~~ public ~~incident happened on~~ the ~~opening ceremony of~~ the 2008 Beijing Summer Olympics in China, ~~when~~ one of the projectors crashed ~~because of a BSOD bug~~.

	=Conclusion=		=Conclusion=

Cha0s: /* Conclusion */

2010-10-15T09:46:21Z

Conclusion

← Older revision		Revision as of 09:46, 15 October 2010
Line 125:		Line 125:
	=Conclusion=		=Conclusion=

	Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any real world system is capable of experiencing a race condition, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.		Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any real world system is capable of experiencing a race condition, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical and essential systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.

	=References=		=References=

Cha0s: /* Conclusion */

2010-10-15T09:43:37Z

Conclusion

← Older revision		Revision as of 09:43, 15 October 2010
Line 124:		Line 124:

	=Conclusion=		=Conclusion=
	The main challenge with race condition errors is that they're usually unpredictable and can be triggered in various ways depending on the processes involved, the implementation of software, the hardware design and the surrounding environment. However, the human element plays a huge part here as well, as far as applying the required amount of testing, anticipating possible schemes and coming up with different situations where an error might occur.

	A handful of commercial software tools have been developed to address and detect race conditions errors. Most recently, a US software company that goes by the name of ReplaySolutions has been awarded a patent from the US government for developing an innovative kit for debugging race conditions found in software.

	As the industry strives for faster and more efficient level of performance through the use of multi-processor systems and multi-core chips, this area continues to be a vast field for research and innovation within the computing world.

	Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any real world system is capable of experiencing a race condition, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.		Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any real world system is capable of experiencing a race condition, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.

Cha0s at 09:43, 15 October 2010

2010-10-15T09:43:00Z

← Older revision		Revision as of 09:43, 15 October 2010
Line 123:		Line 123:
	The BSOD has surfaced on a number of Windows versions including Windows 7. It has also caused system failures in airports, ATM machines and street hoardings. However, the most notable public incident happened on the opening ceremony of the 2008 Beijing Summer Olympics in China, when one of the projectors crashed because of a BSOD bug.		The BSOD has surfaced on a number of Windows versions including Windows 7. It has also caused system failures in airports, ATM machines and street hoardings. However, the most notable public incident happened on the opening ceremony of the 2008 Beijing Summer Olympics in China, when one of the projectors crashed because of a BSOD bug.

	=~~Conclusions~~=		=Conclusion=
	The main challenge with race condition errors is that they're usually unpredictable and can be triggered in various ways depending on the processes involved, the implementation of software, the hardware design and the surrounding environment. However, the human element plays a huge part here as well, as far as applying the required amount of testing, anticipating possible schemes and coming up with different situations where an error might occur.		The main challenge with race condition errors is that they're usually unpredictable and can be triggered in various ways depending on the processes involved, the implementation of software, the hardware design and the surrounding environment. However, the human element plays a huge part here as well, as far as applying the required amount of testing, anticipating possible schemes and coming up with different situations where an error might occur.

Line 129:		Line 129:

	As the industry strives for faster and more efficient level of performance through the use of multi-processor systems and multi-core chips, this area continues to be a vast field for research and innovation within the computing world.		As the industry strives for faster and more efficient level of performance through the use of multi-processor systems and multi-core chips, this area continues to be a vast field for research and innovation within the computing world.

			Obviously, there is a wide range of problems that can occur due to race conditions. The problem is that any real world system is capable of experiencing a race condition, and it is impossible to simulate how the software will react to every possible hardware setup it might be coupled with. The examples above show that it is very important that life-critical systems should have a higher standard of testing. With the incident involving the Therac-25, it is clear that legacy code should be thoroughly tested when implemented in a new system. With the 2003 blackout, it is clear that when installing in a new environment, the users should put the system through adequate testing themselves before using it in real-world applications. The Mars-Rover incident shows that even without implementation of old code or different environments race conditions can go unnoticed, bringing light to the fact that every possible combination of events should be tested, when failure could end up costing millions of dollars. Of course, on the more common side of things, the BSOD shows that even systems used in millions of computers are still capable of having deeply embedded bugs not yet fixed. So, while race conditions can not always be avoided, a higher standard of testing would greatly decrease the probability of it occurring.

	=References=		=References=