Differences between version 6 and revision by previous author of RaceCondition.
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 6 | Last edited on Monday, October 18, 2004 5:14:30 am | by AristotlePagaltzis | Revert |
| Older page: | version 4 | Last edited on Monday, October 18, 2004 5:09:56 am | by StuartYeates | 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 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
. File operations should if at all possible be [Atomic].
+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.
