std::atomic_flag and std::lock_guard

Question

Since std::lock_guard doesn't work with std::atomic_flag I've implemented my own version:

class atomic_guard { public: inline atomic_guard(std::atomic_flag& lock) : lock(lock) { while (this->lock.test_and_set()) { /* spin */ }; }; inline ~atomic_guard() { this->lock.clear(); }; private: std::atomic_flag& lock; };

This seems to work fine. The question is: is this a correct way to implement RAII for std::atomic_flag? Also is there a built-in guard for that? If not, why? The specialization std::lock_guard<std::atomic_flag> looks like something very natural.

LWimsey · Accepted Answer · 2017-04-21 16:05:53Z

5

Your use of atomic_guard as a standalone mutex lookalike is correct, if slightly unusual.

Using std::atomic_flag directly with std::lock_guard is not possible because the std::lock_guard template manages a mutex while std::atomic_flag is a (low-level) atomic boolean type.

A mutex implementation that can be used with std::lock_guard has to provide member functions lock and unlock and can be implemented like this:

class my_mutex { std::atomic_flag flag{ATOMIC_FLAG_INIT}; public: void lock() { while (flag.test_and_set()); } void unlock() { flag.clear(); } };

Note that this is a very basic and inefficient mutex implementation, but it is compatible with std::lock_guard:

my_mutex mtx; std::lock_guard<my_mutex> lck{mtx};

answered Apr 21, 2017 at 16:05

LWimsey

6,7672 gold badges31 silver badges60 bronze badges

Sign up to request clarification or add additional context in comments.

5 Comments

freakish Over a year ago

What do you mean by inefficient? Isn't atomic_flag more efficient then standard mutex? At least for some cases, e.g. when the locking time is supposed to be short.

LWimsey Over a year ago

@freakish If a thread is waiting to acquire the lock using my_mutex, it is wasting a lot of CPU time since it is in a busy while loop

freakish Over a year ago

I wouldn't call that "wasting". You gain execution time, so its a tradeof. It seems that atomic_flag can be even ~50x faster then standard mutex. So if you lock for a short period then "wasting" these cpu cycles might be worth it. Here's the benchmark: arangodb.com/2015/02/comparing-atomic-mutex-rwlocks Of course I will do proper tests in my scenario, but I do expect at least 2x speedup.

freakish Over a year ago

But I do like your my_mutex implementation. I didn't know that you can use std::lock_guard with a custom class (and that it is so easy). That's very nice.

LWimsey Over a year ago

@freakish I have done some performance comparison with a std::mutex (easy to replace in lock_guard).. Usually the standard library mutex wins. Obviously that implementation is more advanced. I believe it also loops for a short time before a context switch is performed

Collectives™ on Stack Overflow

std::atomic_flag and std::lock_guard

1 Answer 1

5 Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

5 Comments

Related