Mutex for simple data types

Question

I'm pretty new to concurrency, and I'm having trouble deciding on how to use mutexes. At the moment they are sprinkled all over my code where two threads interact. Would this use of mutexes be appropriate?

class Foo
{
public:
    void SetMember(int n) {  AcquireMutex(..); n_ = n; ReleaseMutex(...);}
private:
   Thread()
   {
      while(1)
      {
         AcquireMutex(..);
         // Do something with n_
         ReleaseMutex(...);
       }
   }
};

I have quite a few data members that can be read and set from the outside by a different thread, and I'm finding it to be a headache to keep track of all the acquiring and releasing of mutexes.

Name the mutex after the variable being protected eg. n_mutex (for n). Also you need to consider what to do if more than one variable need to be updated when changing the state of your class object eg. setting a size to 0 and deleting a pointer when resetting something. Also consider atomics for primitave types. — Richard Critten, Aug 04 '15 at 12:11
I don't have access to C++11, which I guess means I can't use atomics? — Q-bertsuit, Aug 04 '15 at 12:19
@Q-bertsuit You can't use the standard library's atomics, but if you're using C++/CLI, I think Microsoft has their own atomic operations — KABoissonneault, Aug 04 '15 at 12:20
@Q-bertsuit That's a shame :/ C++11 added a *ton* of nice stuff for multithreaded code including ``, ``, `` etc. — Cory Kramer, Aug 04 '15 at 12:20

Cory Kramer · Accepted Answer · 2015-08-04T12:13:41.567

3

Mutation of primitive types is not guaranteed to be thread safe, or more specifically atomic. In fact, if you look in <atomic> you will notice that there are several specializations, including std::atomic_int.

From cppreference

Objects of atomic types are the only C++ objects that are free from data races; that is, if one thread writes to an atomic object while another thread reads from it, the behavior is well-defined.

To specifically answer your question about the use of mutexes, yes your use of mutexes is fine in your example. In general, you want to hold a mutex for as short as possible. In other words, if you have a function that does a lot of work, only lock the mutex around the un-threadsafe code, then unlock it as soon as the code is threadsafe afterwards.

edited Aug 04 '15 at 12:13

answered Aug 04 '15 at 12:11

Cory Kramer

114,268
16
167
218

So any data that can be read/written to by two threads and are not atomic must use mutexes(or semphores etc.)? – Q-bertsuit Aug 04 '15 at 12:13
@Q-bertsuit mutexes do 2 jobs, (1) locking (2) memory fence. – Richard Critten Aug 04 '15 at 12:14
Thank you. As a side question; should I use different mutexes for different data (one for foo_, one for bar_ etc.) or is a single mutex fine? – Q-bertsuit Aug 04 '15 at 12:16
1

@Q-bertsuit You would want to use seperate mutexes. It prevents thread-starving as Thread2 shouldn't have to wait for Thread1 to unlock foo_ if it doesn't care about foo_ and only wants bar_. However, if foo_ and bar_ are *both needed simultaneously* the use of 2 (or more) mutexes can cause a deadlock unless you are careful about a defined acquisition order of the mutexes by threads. – Cory Kramer Aug 04 '15 at 12:19
@CoryKramer and Q-bertsuit, mutexes should be locked around whatever is conceptually an atomic operation. This could involve a single variable or many. For example, if you keep your data in two containers in the same time, say in a map and in a list, you want to lock a single mutex around updating both of them. Otherwise another thread may see the map updated but not the list. – BitWhistler Aug 04 '15 at 13:09
@BitWhistler That is good advice. Discussing good programming practice for multi-threaded code is obviously a very complex topic. I would suggest that the OP read [C++ Concurrency in Action](http://www.amazon.com/dp/1933988770/?tag=stackoverfl08-20) from [The Definitive C++ Book Guide and List](https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list). That book covers all of these considerations in great detail, with code examples as well. – Cory Kramer Aug 04 '15 at 13:28

score 1 · Answer 2 · answered Aug 04 '15 at 12:24

This approach of mutual exclusion is pretty naive and it will not avoid the problems of deadlock and other issues with concurrency.

You must explicitly identify the places in your code where simultaneous accesses by two processes would cause a problem and protect them in a critical section. And you must make sure that you will not let two processes start an operation that they cannot complete because of another process.

At other places, there could be no need for protection and activating a mutex would be overkill.

Very often, atomicity is required not for a single variable but for a set of coupled variables.

Mutex for simple data types

2 Answers2

Linked