Differences between version 7 and predecessor to the previous major change of RaceCondition.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 7 | Last edited on Thursday, May 4, 2006 9:28:25 am | by IanMcDonald | Revert |
| Older page: | version 6 | Last edited on Monday, October 18, 2004 5:14:30 am | by AristotlePagaltzis | Revert |
@@ -1,5 +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. RaceCondition~s are a particularly challenging when writing InterruptHandler~s
in the [Kernel]
or SignalHandler~s in applications.
+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 any code
in the LinuxKernel as it is fully re-entrant
or SignalHandler~s in applications.
Many security-related RaceCondition~s have been found where programs would check file properties (such as existence, permissions, and/or ownership) before operating on a file. The obvious implementation of this is a RaceCondition, because these file properties can be changed between the check and operation. 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.
