Non-Blocking Mutex Acquisition with `pthread_mutex_trylock`

The Non-Blocking Alternative: pthread_mutex_trylock

Sometimes, a thread shouldn't just wait. It might have other useful work to do, or it might need to try acquiring a different resource if its first choice is busy. For these scenarios, Pthreads provides pthread_mutex_trylock.

Let's start with a quick conceptual overview of this function.

As the video explains, pthread_mutex_trylock attempts to acquire a lock and returns immediately. This behavior is what makes it "non-blocking."

For a more formal definition, let's look at the documentation.

To summarize the key points:

• Function Signature: int pthread_mutex_trylock(pthread_mutex_t *mutex);
• Behavior:
  • If the mutex is unlocked, the function acquires the lock, sets the calling thread as the owner, and returns 0.
  • If the mutex is already locked (by any thread), the function returns immediately with the error code EBUSY. The calling thread does not block.
• Your Code's Responsibility: Your program must check the return value of pthread_mutex_trylock to determine if the lock was acquired and then act accordingly.

int result = pthread_mutex_trylock(&my_mutex);

if (result == 0) {
    // Success! We have the lock.
    // --- Start of Critical Section ---
    // ... do work with shared data ...
    // --- End of Critical Section ---
    pthread_mutex_unlock(&my_mutex);
} else if (result == EBUSY) {
    // The lock is held by another thread.
    // ... do some other work, or try again later ...
} else {
    // Some other error occurred.
    // ... handle error ...
}

Now, let's explore a practical scenario where this is incredibly useful.

Use Case 1: Managing a Pool of Equivalent Resources

Imagine you have a set of identical resources that threads need to use—for example, a pool of four database connections, or four "stoves" in a kitchen that "chefs" (threads) can use for cooking. A chef doesn't care which stove they get, only that they get an available one.

Using pthread_mutex_lock here would be inefficient. A thread might pick stove #1 and block, waiting for it to become free, even though stoves #2, #3, and #4 are available.

This is a perfect application for pthread_mutex_trylock. A thread can iterate through the resources, trying to lock each one. The first successful trylock gives it a resource to work with, and it can proceed without having to wait.

The following video provides a complete, practical example of this pattern.

The core logic demonstrated in the video is a powerful and common pattern:

1. Setup: Create an array of resources and a corresponding array of mutexes, one for each resource.

   pthread_mutex_t stove_mutexes[4];
   // Initialize all 4 mutexes...
   

2. Acquisition Loop: A thread loops through the mutexes, using trylock on each one.

   for (int i = 0; i < 4; i++) {
       if (pthread_mutex_trylock(&stove_mutexes[i]) == 0) {
           // Got a lock!
           printf("Thread %ld is using stove %d\n", pthread_self(), i);
           // ... use the resource ...
           pthread_mutex_unlock(&stove_mutexes[i]);
           
           // Break the loop since we've done our work.
           break; 
       }
   }
   

3. Handling Contention: What if all resources are busy? The loop will complete without acquiring a lock. The video shows a clever way to handle this: if the loop finishes unsuccessfully, the thread can sleep for a short duration and then restart the loop from the beginning, effectively polling for an available resource.

int retries = 0;
while (retries < 5) {
    int lock_acquired = 0;
    for (int i = 0; i < NUM_STOVES; i++) {
        if (pthread_mutex_trylock(&stove_mutexes[i]) == 0) {
            // Got a lock
            printf("Chef is cooking on stove %d\n", i);
            // ... work ...
            pthread_mutex_unlock(&stove_mutexes[i]);
            lock_acquired = 1;
            break; // Exit the inner for-loop
        }
    }

    if (lock_acquired) {
        break; // Exit the outer while-loop
    }

    // If we get here, no stove was available in this pass
    printf("All stoves busy, waiting...\n");
    retries++;
    sleep(1); // Wait a bit before retrying
}

if (retries == 5) {
    printf("Kitchen too busy, going home.\n");
}

Use Case 2: Deadlock Avoidance

In a future module, we'll cover deadlocks in depth. For now, a simple definition will suffice: a deadlock occurs when two or more threads are blocked forever, each waiting for a resource held by the other. A common cause is acquiring multiple locks in an inconsistent order.

The standard solution is to enforce a strict lock-ordering policy (e.g., always lock mutex A before mutex B). But what if your program's logic makes this difficult? pthread_mutex_trylock offers an alternative.

The pattern described is as follows: to acquire locks L1 and L2 without risk of deadlock:

1. Lock L1.
2. Use trylock on L2.
3. If trylock(L2) succeeds, you hold both locks. Proceed.
4. If trylock(L2) fails (returns EBUSY), you must immediately unlock L1 and then restart the entire process.

By releasing L1, you break the "hold and wait" condition necessary for deadlock, allowing another thread that might be waiting for L1 to proceed.

This approach, while effective, can introduce a new, related problem called livelock. This happens if two threads repeatedly attempt this sequence, block each other, back off, and retry, without ever making progress. As the reading suggests, introducing a small random delay before retrying is a common way to mitigate this.

Conclusion

You have now added a crucial non-blocking tool to your concurrency toolkit. While pthread_mutex_lock is the workhorse for simple mutual exclusion, pthread_mutex_trylock gives you the flexibility to build more sophisticated and responsive concurrent systems.

Key Takeaways:

• pthread_mutex_trylock is a non-blocking function that attempts to acquire a lock and returns immediately.
• It returns 0 on success and EBUSY if the lock is already held, requiring your code to check the return value.
• It is ideal for scenarios with a pool of equivalent resources, allowing a thread to grab the first one available without waiting.
• It provides a powerful strategy for deadlock avoidance by allowing a thread to "back off" and release its locks if it cannot acquire all the locks it needs.

Preview of the Next Lesson:
So far, our threads have communicated only by competing for locks. But what if one thread needs to wait for another thread to complete a task or signal that some data is ready? For example, a "consumer" thread might need to wait for a "producer" thread to add an item to a queue. This requires more than just a mutex. In the next lesson, we will introduce a new synchronization primitive designed for this exact purpose as we learn to initialize and destroy condition variables alongside their associated mutexes.