Synchronizing access to data using a "got there first" flag, instead of a lock/mutex

Question

Suppose we have a function which accesses some globally shared data - and suppose this function will be called by multiple concurrent threads.

Naturally, we need to somehow synchronize access to this data. Is it possible to do this via a mechanism where we have an atomic flag, and whichever thread manages to set the flag can then proceed to access the shared data? Whereas the losing threads will not block on a lock, but simply return from the function.

Something like the following:

Given some globally shared data along with a synchronization flag:

namespace global {

  int x;
  int y;

  std::atomic_flag sync_flag = ATOMIC_FLAG_INIT;

}

And our function which will be accessed by concurrent threads:

void race()
{
   // See if we won the race
   //
   if (!global::sync_flag.test_and_set())
   {
      // We won
      //
      global::x = 10;
      global::y = 11;
   }
   else
   {
     // We lost... 
     return;
   }
}

Does the above code guarantee that global::x and global::y will be safely accessed by only a single thread, and that no race conditions will occur? Or is this not guaranteed due to memory ordering problems?

Note we never actually locked a mutex or anything, so no thread ends up blocking. The idea here is simply to ensure that only one thread is allowed to access (non-atomic) global variables here.

Of course, after the winning thread is done, we would need to somehow safely clear the atomic flag if we ever intend on calling race() again. That is a problem I haven't thought much about yet, but it is really beyond the scope of this question.

So is the above code race-condition free (for a single call to race())?

Answer 1

I see nothing here that cannot be accomplished with bog-standard std::mutex.

std::mutex does not require you to pause and wait until the mutex is acquired.

See the documentation for std::unique_lock's constructor that takes an optional second argument of std::try_to_lock_t. If the mutex can be acquired, it gets acquired. Otherwise, you keep going.

It's always better to stick to the standard, and tested, library functions, especially when they seem to already meet the desired requirements, instead of trying to roll one's own.

Answer 2

Yes. Only one thread can get the not-yet-set test on the flag. This has an advantage over a mutex in that on some architectures the atomic flag can be done with lock-free operations.

Answer 3

The interface of std::atomic_flag is pretty straightforward. According to the reference and the example it provides, your code should work correctly (until you call race() the second time, of course).

Answer 4

Yes. In fact, this is precisely how a call to try_lock on a mutex would work.

Your assumption that the use of mutexes inherently involves blocking threads is incorrect. We usually call lock on them which, by convention, blocks while waiting for the mutex to become available. But there's no reason you actually have to. Mutexes themselves don't block anything. As far as I can tell, they're just wrappers around atomic flags.

Answer 5

What you have is almost correct. What you are trying to do is feasible with std::atomic_flag.

void race()
{
   // See if we won the race
   // NEW CODE - pass std::memory_order_acquire
   if (!global::sync_flag.test_and_set(std::memory_order_acquire))
   {
      // We won
      //
      global::x = 10;
      global::y = 11;

      // NEW CODE - release the flag
      global::sync_flag.clear(std::memory_order_release);         
   }
   else
   {
     // We lost... 
     return;
   }
}

This code is race condition free.

Reference: http://en.cppreference.com/w/cpp/atomic/atomic_flag