0

I'm recent to learning threads and there's a thought that I have in my mind. Let's say I have the following code:

#include <iostream>
#include <thread>
#include <mutex>
using namespace std;

int myAmount = 0;
std::mutex m;

void addMoney(){
    m.lock();
    myAmount++;
    m.unlock();
}

int main(){
    thread t1(addMoney);
    thread t2(addMoney);
    t1.join();
    t2.join();
    cout<<addMoney<<endl;
    return 0;
}

Here mutex prevents the race condition by locking the thread application until it gets finished. Till the thread is working, another thread t2 is kept in a queue. Once thread t1 is finished, the variable in the data segment of the memory gets updated and the queue passes on permitting thread t2 to work. We know we use threads for parallel processing, but here the processing of the threads is sequential rather than parallel. So if I write a single thread version of the above code, which would run faster? The multi-threaded one or the single-threaded one?

Please correct me where I'm wrong about the concept.

Ranoiaetep
  • 5,872
  • 1
  • 14
  • 39
Navyansh Mahla
  • 1
  • 2
  • 3
    `t2` might run first, fyi. – ChrisMM Jan 07 '23 at 17:31
  • 7
    Mutex’s are generally used for brief sections that need to be mutually exclusive. The bulk of the code should run unfettered. This example is really not any kind of motivation for threading at all. – wcochran Jan 07 '23 at 17:32
  • 1
    Sure, incrementing a variable twice will be orders of magnitude faster in a single thread. Also, in your example 100% of your logic is in the critical section. But let's imagine those threads would do real work and be largely independet. A quick search yielded two questions, that should explain the problem (which isn't restricted to C++) https://stackoverflow.com/questions/27319446 and https://stackoverflow.com/questions/46759930/ – Lukas-T Jan 07 '23 at 17:35
  • 1
    Creating threads is expensive work, incrementing an int is orders of magnitude cheaper task. So creating thread for incrementing int is horrible pessimization. – Öö Tiib Jan 07 '23 at 17:35
  • It's really easy to write multithreaded code that's WORSE than the single threaded version because the threads start fighting over access to a single resource. You have to choose threading opportunities carefully. – user4581301 Jan 07 '23 at 17:36
  • Short programs like yours can be useful to demonstrate threading concepts, but rarely will such a short program *benefit* from threading. When you start thinking "but wouldn't single-threaded be better" for one of these demonstrations, you are probably overlooking the fact that a slew of details were left out (which is appropriate for a demonstration or an example). – JaMiT Jan 07 '23 at 17:56
  • @ChrisMM how can you say that? – Navyansh Mahla Jan 07 '23 at 18:40
  • Threads have overhead costs, they need time to startup and if you have possible dataraces you need syncrhonization. So you need enough work that can be done in parallel to make threads worth while. A very important rule is to use mutexes to lock code for the shortest possible time. Only to affect a state change or to write or read some heap memory (try to do the most work on local variables) – Pepijn Kramer Jan 07 '23 at 19:39
  • 3
    @NavyanshMahla System scheduler can do anything it want with threads. A possible sccenario would be that it runs main thread as long as it can to avoid context switch (so until first `join()`), then it has two threads that should run and chooses one at random. Or chooses the newest one, just because it may have more important work to do (the other thread is already waiting, it can wait a moment more). Schedulers are complicated to ensure efficiency, and thus you should always assume anything in threads in indeterminate unless you specifically work to ensure some order. – Yksisarvinen Jan 07 '23 at 19:57

0 Answers0