Differences between version 4 and predecessor to the previous major change of RaceCondition.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Monday, October 18, 2004 5:09:56 am | by StuartYeates | Revert |
| Older page: | version 1 | Last edited on Sunday, August 24, 2003 6:29:54 pm | by StuartYeates | Revert |
@@ -1,3 +1,5 @@
-A [RaceCondition] is a [Synchronisation] bug in which the results of some computation or action depend in an unsafe way upon the the actions of other threads or processes.
+A [RaceCondition] is a [Synchronisation] bug in which the results of some computation or action depend in an unsafe way upon the the actions of other threads or processes. [RaceCondition]s are a particularly challenging when writing [InterruptHandler]s in the [Kernel] or [SignalHandler]s in applications
.
-Several security-related [RaceCondition]s have occurred when a program checks file permissions and ownership before reading the file. The obvious implementation of this has a [RaceCondition] which allows the file to be changed between the check and the reading.
+Several security-related [RaceCondition]s have occurred when a program checks file permissions and ownership before reading the file. The obvious implementation of this has a [RaceCondition] which allows the file to be changed between the check and the reading. File operations should if at all possible be [Atomic].
+
+A DeadLock is perfered to a RaceCondition, because with a DeadLock, something is obviously wrong, whereas a RaceCondition can give no indication of a problem until someone notices corrupt data or a security breach
.
