Locking a part of memory for multithreading

Question

I'm trying to write some code that creates threads that can modify different parts of memory concurrently. I read that a mutex is usually used to lock code, but I'm not sure if I can use that in my situation. Example:

using namespace std;
mutex m;
void func(vector<vector<int> > &a, int b)
{
    lock_guard<mutex> lk(m);
    for (int i = 0; i < 10E6; i++) { a[b].push_back(1); }
}

int main()
{
    vector<thread> threads;
    vector<vector<int> > ints(4);
    for (int i = 0; i < 10; i++)
    {
        threads.push_back(thread (func, ref(ints), i % 4));
    }
    for (int i = 0; i < 10; i++) { threads[i].join(); }
    return 0;
}

Currently, the mutex just locks the code inside func, so (I believe) every thread just has to wait until the previous is finished.

I'm trying to get the program to edit the 4 vectors of ints at the same time, but that does realize it has to wait until some other thread is done editing one of those vectors before starting the next.

This is just an example I came up with. I'm trying to write code that is allowed to use the 4 different vectors I made simultaneously from different threads. — RobVerheyen, May 21 '14 at 12:37
`a[b].resize(a[b].size() + 10E6, 1);` would likely be more efficient than `for (int i = 0; i < 10E6; i++) { a[b].push_back(1); }`. — Casey, May 21 '14 at 16:42

score 3 · Accepted Answer · answered May 21 '14 at 12:40

3

I think you want the following: (one std::mutex by std::vector<int>)

std::mutex m[4];
void func(std::vector<std::vector<int> > &a, int index)
{
    std::lock_guard<std::mutex> lock(m[index]);
    for (int i = 0; i < 10E6; i++) {
        a[index].push_back(1);
    }
}

answered May 21 '14 at 12:40

Jarod42

203,559
14
181
302

So now a thread has to wait only if it tries to lock a mutex that is already locked, right? That seems to do the trick! – RobVerheyen May 21 '14 at 12:45
The thread has only to wait if it tries to modify the same `std::vector` (indexed by `index`) as an other working thread. – Jarod42 May 21 '14 at 12:54
Follow-up question if you don't mind: What would you do if you don't know the required amount of mutexes before running part of the code? – RobVerheyen May 21 '14 at 14:25
You may keep the `std::mutex` with the shared resource: something like `std::vector>>` – Jarod42 May 21 '14 at 14:37
What does the pair achieve? I'm trying to just use a 'vector', but it won't allow me to 'push_back' mutexes into it. – RobVerheyen May 21 '14 at 14:57
`std::pair` is basicaly a `struct {A first; B second;};`. `std::mutex` is not copyable/movable, so in fact you should replace `std::mutex` by `std::unique_ptr` in my precedent message. – Jarod42 May 21 '14 at 16:12

score 1 · Answer 2 · edited May 23 '17 at 10:32

1

Have you considered using a semaphore instead of a mutex?

The following questions might help you:

Semaphore Vs Mutex

When should we use mutex and when should we use semaphore

edited May 23 '17 at 10:32

Community

1
1

answered May 21 '14 at 12:34

djikay

10,450
8
41
52

score 0 · Answer 3 · answered May 21 '14 at 12:31

0

try:

void func(vector<vector<int> > &a, int b)
{
    for (int i=0; i<10E6; i++) {
        lock_guard<mutex> lk(m);
        a[b].push_back(1);
    }
}

You only need to lock your mutex while accessing the shared object (a). The way you implemented func means that one thread must finish running the entire loop before the next can start running.

answered May 21 '14 at 12:31

doron

27,972
12
65
103

Won't this just hammer the mutex? I mean, even if this "works" it may be a performance pessimization. – John Zwinck May 21 '14 at 12:32
But does this let the code access the different vectors simultaneously? It seems like it just switches between iterations, placing a '1' in every vector after the other. I ran the code. The process uses all my cores, but it takes much longer than the example in my opening post. – RobVerheyen May 21 '14 at 12:36
properly implemented mutexes are cheap. Typically they are implemented entirely userside for cases where there is no contention and involve just executing a few assembler instructions. If you are depending on parallelization for performance reasons, keep the time you are locking mutexes to a minimum – doron May 21 '14 at 12:37

Locking a part of memory for multithreading

3 Answers3