A variable visible to all threads

[std10093]

I want to write a program where, random numbers are going to be created and I am going to track down the greatest of them. Three threads are going to run in parallel.

I do it with two methods. First I create a variable in main(), which then I pass by ref. to every thread. At the end, this variable holds the maximum value generated. When the variable is updated, I use a mutex (do I really have to?).

The second method uses std::atomic and produces the same results (as far as I tested it).

This is a minor example I do, in order to use in my project, where it is critical that all the threads can see the current best value found by all the threads.

Here is the code:

#include <iostream>       // std::cout
#include <thread>         // std::thread
#include <mutex>          // std::mutex
#include <atomic>
#include <random>

std::default_random_engine generator((unsigned int)time(0));
int random(int n) {
  std::uniform_int_distribution<int> distribution(0, n);
  return distribution(generator);
}

std::mutex mtx;           // mutex for critical section
std::atomic<int> at_best(0);

void update_cur_best(int& cur_best, int a, int b) {
  // critical section (exclusive access to std::cout signaled by locking mtx):
  if(cur_best > a && cur_best > b)
    return;
  if(at_best > a && at_best > b)
        return;
  int best;
  if(a > b)
    best = a;
  else
    best = b;
  mtx.lock();
  cur_best = best;
  mtx.unlock();


  // or

  if(a > b)
    at_best = a;
  else
    at_best = b;
}

void run(int max, int& best) {
    for(int i = 0; i < 15; ++i) {
        update_cur_best(best, random(max), random(max));
    }
}

//g++ -std=c++0x -pthread px.cpp -o px
int main ()
{
  int best = 0;
  std::thread th1 (run, 100, std::ref(best));
  std::thread th2 (run, 100, std::ref(best));
  std::thread th3 (run, 100, std::ref(best));

  th1.join();
  th2.join();
  th3.join();

  std::cout << "best = " << best << std::endl;
  std::cout << "at_best = " << at_best << std::endl;

  return 0;
}

The questions:

1) Are the two methods equivalent?

From the ref: "Atomic types are types that encapsulate a value whose access is guaranteed to not cause data races and can be used to synchronize memory accesses among different threads."

Are they equivalent by terms of the results they produce and efficiency?

2) If they are, then why is atomic introduced? What method should I use? Speed is what I am interested in.

3) Is there any faster method to achieve this functionality?

Remember that for my actual project, the point is that best will have the current best value from all the threads, in order to make comparison easier.

Probably they are not equivalent. I feel that I am not at the right track. How should I approach the problem then?

[King Mir]

I want to write a program where, random numbers are going to be created and I am going to track down the greatest of them. Three threads are going to run in parallel.

I do it with two methods. First I create a variable in main(), which then I pass by ref. to every thread. At the end, this variable holds the maximum value generated. When the variable is updated, I use a mutex (do I really have to?).

The second method uses std::atomic and produces the same results (as far as I tested it).

This is a minor example I do, in order to use in my project, where it is critical that all the threads can see the current best value found by all the threads.

Here is the code:

#include <iostream>       // std::cout
#include <thread>         // std::thread
#include <mutex>          // std::mutex
#include <atomic>
#include <random>

std::default_random_engine generator((unsigned int)time(0));
int random(int n) {
  std::uniform_int_distribution<int> distribution(0, n);
  return distribution(generator);
}

std::mutex mtx;           // mutex for critical section
std::atomic<int> at_best(0);

void update_cur_best(int& cur_best, int a, int b) {
  // critical section (exclusive access to std::cout signaled by locking mtx):
  if(cur_best > a && cur_best > b)
    return;
  if(at_best > a && at_best > b)
        return;
  int best;
  if(a > b)
    best = a;
  else
    best = b;
  mtx.lock();
  cur_best = best;
  mtx.unlock();


  // or

  if(a > b)
    at_best = a;
  else
    at_best = b;
}

void run(int max, int& best) {
    for(int i = 0; i < 15; ++i) {
        update_cur_best(best, random(max), random(max));
    }
}

//g++ -std=c++0x -pthread px.cpp -o px
int main ()
{
  int best = 0;
  std::thread th1 (run, 100, std::ref(best));
  std::thread th2 (run, 100, std::ref(best));
  std::thread th3 (run, 100, std::ref(best));

  th1.join();
  th2.join();
  th3.join();

  std::cout << "best = " << best << std::endl;
  std::cout << "at_best = " << at_best << std::endl;

  return 0;
}

Your code is wrong.

You can't have multiple threads read from a variable like cur_best when another thread may be writing to it. You need to mutex both the reads and the writes, because you can't have one thread read, while another thread writes without synchronization. You can use a shared_mutex to allow multiple reads at the same time, but only one write. Or you can make the parameter a reference to an atomic variable.

You also need to ensure that the best value isn't changed by another thread between the time you determine that it needs to be changed, and when you actually write to it. You can do this by checking that the value is still what you expect inside the critical section, before writing it in in mutex version. In the atomic version, you need to use compare_exchange.

1) Are the two methods equivalent?

From the ref: "Atomic types are types that encapsulate a value whose access is guaranteed to not cause data races and can be used to synchronize memory accesses among different threads."

Are they equivalent by terms of the results they produce and efficiency?

2) If they are, then why is atomic introduced? What method should I use? Speed is what I am interested in.

In general, it is possible to write the same code with either mutexes or atomics. If the data shared is small, like a primitive type, atomics are faster. If the shared memory is a large class, and only some of the members need to be read or written to, a mutex is better. Only trivially copyable types can be atomic. Large classes where you need to read and write the whole thing every time is rare, but in this case it doesn't matter which is used.

Note if you're sharing several pieces of data that are logically connected, you need one mutex/lock, or one atomic that contains all that data.

3) Is there any faster method to achieve this functionality?

You can use a weaker memory order on atomics than the default. The performance gain of this depends a lot on the processor architecture. Knowing weakest memory order that you can use is considered advanced knowledge, and not worth bothering with on x86 systems.

[std10093]

Ok I see. I will have to read the theory behind the weaker memory order, but I got the big picture.

However, in this problem it would be more reasonable to let the threads run (without communication) and then compare the best found by each one of them. I wonder if this opinion applies to my actual project too. Worth some testing I guess.

Thanks!

[King Mir]

I wouldn't worry about weak memory order until well after you learn and are comfortable with using mutexes correctly.

[antred]

From your code sample above:

mtx.lock();
cur_best = best;
mtx.unlock();

Don't lock / unlock mutexes explicitly. It's prone to errors ... not so much in such a simple case, but what happens if something throws an exception after you've locked the mutex but before you've locked it? You'll never even get to the line where you unlock the mutex. Use std::lock_guard to avoid this issue:

{
    // create lock guard (c'tor automatically locks the mutex)
    std::lock_guard< std::mutex > l( mtx );

    cur_best = best;
} // <- close scope ... upon leaving scope, the destructor of the lock guard unlocks the mutex, even in the face of exceptions

[antred]

what happens if something throws an exception after you've locked the mutex but before you've locked it?

Hate to quote myself, but apparently I can no longer edit my post. Obviously I meant what happens if something throws an exception after you've locked the mutex but before you've unlocked it?

[Elkvis]

Hate to quote myself, but apparently I can no longer edit my post. Obviously I meant what happens if something throws an exception after you've locked the mutex but before you've unlocked it?

If locked, std::lock_guard releases the mutex when it goes out of scope. std::lock_guard - cppreference.com

[antred]

Um, yeah, I'm aware of that. That's the whole point of me suggesting that he use std::lock_guard instead of doing it manually.

[std10093]

Thanks for the information!

[iMalc]

From your description, the way to do it is not to have three threads touch the same variable.
Instead each thread should find its own "best" value, then once all threads have completed examine all three bests and pick the best of those three.
No locking will be required!