static lock_guard with static mutex too?

Question

So I've some thread-unsafe function call which I need to make thread safe so I'm trying to use a std::mutex and a std::lock_guard. Currently code looks like this -

int myFunc(int value){
    static std::mutex m;
    std::lock_guard lock(m);
    auto a = unsafe_call(value);
    return a;
}

the unsafe_call() being the thread-unsafe function. I've also put static around the mutex because then the function will have different mutexes for each separate call.

What I want to know is, should I also make lock_guard static because the mutex is static one, as I was told by some coworker of mine. I don't see a reason why should I do this, because I consider lock_guard to be a simple .lock() and .unlock() call, but the suggestion from coworker is confusing me.

The static `std::mutex` seems fine (it has to be stored somewhere, maybe could be stored more ellegantly), but as Nathan mentioned - `lock_guard`'s ctor locks the mutex, and dtor unlocks it. If the lock is a static one, the mutex will never be unlocked. — hauron, Feb 14 '17 at 18:02
Your coworker doesn't know what they're talking about. Your understanding of how `lock_guard` works is a helluvalot better than theirs. — WhozCraig, Feb 14 '17 at 18:04
See also this question (tl;dr your code is safe in C++11): https://stackoverflow.com/questions/14106653/are-function-local-static-mutexes-thread-safe — Paul, Dec 07 '20 at 09:33

Slava · Answer 1 · 2017-02-14T18:18:47.527

4

should I also make lock_guard static because the mutex is static one, as I was told by some coworker of mine.

Your coworker is completely wrong, lock_guard is using RAII mechanism to control resource (mutex in this case) and making it static would completely defeat it's purpose - mutex would be locked once on the first execution of the function and released only when program terminates, ie effectively you would not be using mutex at all.

edited Feb 14 '17 at 18:18

answered Feb 14 '17 at 18:04

Slava

43,454
1
47
90

what is RAII mechanism? – hg_git Feb 14 '17 at 18:17

πάντα ῥεῖ · Answer 2 · 2017-02-14T18:18:00.937

I don't see a reason why should I do this, because I consider lock_guard to be a simple .lock() and .unlock() call, but the suggestion from coworker is confusing me.

That suggestion is nonsense IMO, and you're righteously confused about it.

The purpose of std::lock_guard is to make locking/unlocking the mutex guaranteed within a particular scope (and robust against exceptions). This is done using the behavior of the destructor function, that is guaranteed to be called when the variables scope is left.
For a static variable the destructor will be at best called at the end of the processes lifetime. Hence the mutex would be locked by the 1st calling thread with the whole process.

The global scope is very unlikely to be correct/make sense, as it would appear with a static lock_guard.

So your colleague is wrong.

Abhinav Gauniyal · Answer 3 · 2017-02-14T18:31:49.413

1

should I also make lock_guard static because the mutex is static one, as I was told by some coworker of mine.

NO

Consider the scenario where two threads enter your function and both get the same static std::mutex m. One tries to lock it and the other one would not get chance[1]. Furthermore, when the first function exits, it won't actually unlock the mutex since lock_guard is static storage and it's scope is valid here so no destructor will be called.

[1] - std::lock_guard locks in ctor, which would be executed only once if guard is static, second thread would not even try to lock - as corrected by @Slava in comments.

edited Feb 14 '17 at 18:31

answered Feb 14 '17 at 18:07

Abhinav Gauniyal

7,034
7
50
93

@Slava pardon me, that's what I understood while reading somewhere. would you mind correcting me. – Abhinav Gauniyal Feb 14 '17 at 18:11
`std::lock_guard` locks in ctor, which would be executed only once if guard is static, second thread would not even try to lock. – Slava Feb 14 '17 at 18:12
sorry I'm bit new to c++, static disables destructors on return of function calls? – hg_git Feb 14 '17 at 18:18
1

@hg_git static local object lifetime is from first execution to the end of program. You should understand basics of C++ – Slava Feb 14 '17 at 18:23
@hg_git Sounds like you could use a [good C++ book](http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list) – NathanOliver Feb 14 '17 at 18:24
@Slava ah I see, I thought it was from first function execution to last, but on thinking a bit more I see why that's exactly same as program end. – hg_git Feb 14 '17 at 18:28
@NathanOliver definitely, thanks for the suggestions. – hg_git Feb 14 '17 at 18:28
@hg_git how do you know which execution is the last? – Slava Feb 14 '17 at 18:29
@Slava I know I know my reasoning was flawed, I stated the same in my previous comment man.. – hg_git Feb 14 '17 at 18:30
@hg_git your previous comment is incorrect, it is not the same. – Slava Feb 14 '17 at 18:35

static lock_guard with static mutex too?

3 Answers3