Race condition
A result depends on the timing of overlapping accesses and can therefore be wrong.
What is a race condition?
A race condition arises when a result improperly depends on the timing order of concurrent workflows. Several operations often access shared state without suitable coordination. They need not execute simultaneously on multiple processor cores. Interleaved accesses can also produce an unsuitable order.
In a fictional portal, two reservation requests check the same last available item. Both initially see availability and could report success without appropriate protection. Checking and reservation must therefore be protected together so that only one request can successfully reserve the last item; only the result determines the feedback. Merely opening a database transaction does not establish that this conflict is prevented. The team specifically checks overlapping workflows and the protection used.
Sources
Related terms
- Asynchronous programmingWaiting for a result without blocking the rest of the intended workflow.
- ParallelismActually executing several computations at the same time.
- ConcurrencyOrganising multiple tasks so that their processing periods can overlap.
- Database lockA database lock coordinates concurrent access to data or database objects so incompatible operations do not proceed unchecked.
- Optimistic lockingOptimistic locking detects on save whether a record has changed since the version that was read.
- Cache stampedeA cache stampede occurs when concurrent cache misses trigger the same expensive calculation or data query repeatedly.
Your project with ASES
Describe your project to us. We will get back to you with an initial assessment.