Anonymous user
Race condition: Difference between revisions
m
I wonder how long this one was sitting around unnoticed
(Reorganized somewhat.) |
m (I wonder how long this one was sitting around unnoticed) |
||
Line 1:
[[Category:Encyclopedia]]A '''race condition''' describes a class of programming, design or implementation bug in which the outcome of some process or function call can vary depending on the
==Reasons==
In any situation where a resource is shared and potentially concurrently accessible there are possible race conditions.
===File access===
For example, when creating a new file on a local [[UNIX]] or [[Linux]] filesystem two processes might attempt to use the same filename at the same time.
As a further example, the O_EXCL|O_CREAT combination of flags is '''not''' sufficient for providing the same race free
===Shared memory===
Race considerations also apply to shared memory.
The concept of "race conditions" can apply to any form of shared memory or storage resource and many networking and communications domains.
Most popular platforms perform [[multitasking]], where multiple threads of code run on the same computer.
When a thread refers to a piece of memory (i.e. an object), they may make decisions based upon its contents, and it might assume that that object will not change between the time it looks at it and the time when it carries out an action based on that glance.
CObject* pObj = GetSharedObject();
if ( pObj->Available() ) // Check to see if the object is available
{
}
In this code, pObj points to an object (returned by GetSharedObject) that may be shared with other threads. Let's assume for the moment that another thread has also called GetSharedObject(), and received a pointer to the same object we're working with.
Because of the nature of multitasking, it's possible that the second thread might have accessed the shared object ''after'' we checked to see if the object was available, but ''before'' we did something with that object.
==Inconsistency==
While it's possible that another thread with access to our shared
==Solutions==
Line 42 ⟶ 41:
===Locks===
[[Lock|Locks]] are mechanisms that force one thread to wait until another thread is finished with a piece of data.
CObject* pObj = GetSharedObject();
Line 49 ⟶ 48:
if ( pObj->Available() )
{
}
pObj->Unlock();
In the above code, we lock our object before we attempt to do anything with it.
Various sorts of locking primitives include [[semaphore]]s and [[mutex]]es (mutual exclusion objects).
Line 61 ⟶ 60:
Synchronization locks can be designed into threading architectures by encapsulating the locking and unlocking operations in accessor methods for shared memory regions. All access to the shared memory region then enforces the locking policy for all threads.
Languages with built-in threading syntax commonly provide very simple ways to enforce locks. [[Java]] provides the ''synchronized''
[[Ada]] provides ''protected objects'' with locking characteristics based upon the kind of access method described. A protected ''procedure'' enforces a write lock, allowing unconditional access to the object by only a single thread at a time. A protected ''entry'' enforces a write lock, allowing conditional access to the object by one thread at a time. A protected ''function'' provides a shared read lock, allowing multiple read access to the object at the same time. Many locking [http://home.att.net/~jimmaureenrogers/Shared_Resource_Design_Patterns.html patterns] can be defined using these three capabilities.
|