Skip to main content

Race condition

Need​

Ensuring proper synchronization and order of inputs in the system

Context​

  • Usage of Python 3 for scripting and application development
  • Usage of Django for building web applications in Python
  • Usage of myapp for building a custom application

Description​

Non compliant code​

from django.http import HttpResponse
from myapp.models import MyModel

def my_view(request):
    obj = MyModel.objects.get(pk=1)
    obj.field = 'new value'
    obj.save()
    return HttpResponse('OK')

In the code above, the Django view my_view retrieves an object from the database with a primary key of 1, modifies a field of the object, and then saves the object back to the database.

This code is vulnerable to a race condition. A race condition is a situation where the behavior of the software depends on the relative timing of events, such as the order of threads execution.

Here, if two users simultaneously send a request to this view, they might both retrieve the object before either of them has a chance to save their modifications. User A retrieves the object, then User B retrieves the object, then User A saves the object, then User B saves the object. The end result is that User A's changes are lost, because they are overwritten by User B's save.

This is a problem because it can lead to inconsistent data and unexpected behavior. The system is not properly handling the case where the inputs (in this case, the HTTP requests) do not arrive in the expected order.

Steps​

  • Identify the critical section of the code which is causing the race condition. In this case, it's the part where the object is fetched, modified, and saved.
  • Implement a locking mechanism to prevent concurrent access to the critical section. Django provides a few ways to do this, such as using the 'select_for_update' method on the queryset to lock the rows until the end of the transaction.
  • Ensure that the lock is always released, even if an error occurs. This can be done by using 'try/finally' blocks or ensuring that the lock is released in the 'finally' part of a 'try/except/finally' block.
  • Test the code thoroughly to ensure that the race condition has been resolved and that the locking mechanism works as expected without causing deadlocks or other issues.

Compliant code​

from django.db import transaction
from django.http import HttpResponse
from myapp.models import MyModel

def my_view(request):
    try:
        with transaction.atomic():
            obj = MyModel.objects.select_for_update().get(pk=1)
            obj.field = 'new value'
            obj.save()
    except MyModel.DoesNotExist:
        return HttpResponse('Object does not exist')
    except Exception as e:
        return HttpResponse('An error occurred: {}'.format(e))
    return HttpResponse('OK')

The updated code now includes a locking mechanism to prevent race conditions. This is done using Django's transaction.atomic() context manager and the select_for_update() method.

The transaction.atomic() context manager starts a database transaction. This means that all database queries inside the with block are executed as a single atomic unit. If an error occurs, all changes are rolled back.

The select_for_update() method locks the rows until the end of the transaction. This means that other transactions will be prevented from changing the locked rows until the current transaction is complete. This prevents race conditions by ensuring that the rows cannot be modified by another transaction until the current transaction is complete.

The try/except block is used to handle any exceptions that may occur. If the object does not exist, a MyModel.DoesNotExist exception is raised and a response is returned indicating that the object does not exist. If any other error occurs, a general Exception is caught and a response is returned indicating that an error occurred.

This code should be thoroughly tested to ensure that the race condition has been resolved and that the locking mechanism works as expected without causing deadlocks or other issues.

References​

Last updated on