In briefly: I'm working on a little chat program just for fun.I am using threads to control two main parts of the application. I am making a socket controller class based on the following design://this is a main.cpp example for the designstd::mutex mtx;class AThreadedClass{public:    AThreadedClass()    {        running = true;        value1 = 0;        value2 = 0;        value3 = 0;    }    //first method which is used for threads    void run()    {        {            std::lock_guard<std::mutex> lck(mtx);            value1 = 0; value2 = 0; value3 = 0;        }        while (running)        {            {                std::lock_guard<std::mutex> lck(mtx);                value1 += 2; value2 +=1; value3 -= 1;                if (value1 > 1000000)                {                    running = false;                }            }        }    }    //second method used as thread    //this will possible be just a data    //retrieving function, not necessarly    //used as thread    void writeOut()    {        while(running)        {            std::lock_guard<std::mutex> lck(mtx);            std::cout << value1 << ';' << value2 << ';' << value3 << '\n';        }    }private:    int value1, value2, value3;    std::atomic<bool> running;};int main(){    AThreadedClass class1;    std::thread t1(&AThreadedClass::run, &class1);    std::thread t2(&AThreadedClass::writeOut, &class1);    t1.join();    t2.join();    std::cout << Threads finished successfully!\n;    return 0;}So, here are the things I was wondering about:Is this a good way to manage things? (I mean, using classes and their member functions for threads could be a stupid idea :/)Are there possible deadlocks, when I am mixing std::atomic with std::mutex like in the example? (So far it worked perfectly for me)And if I didn't notice an existing question about this, please point to it.
Class member method based multithreading [C++]
c++;c++11;multithreading;c++14
Is this a good way to manage things? (I mean, using classes and their member functions for threads could be a stupid idea :/)No. You don't force any sequencing on the threads.Are there possible deadlocks, when I am mixing std::atomic with std::mutex like in the example? (So far it worked perfectly for me)Yes. Though unlikely.This loop can lock out the other thread from running completely (because it also tries to lock mtx).    while(running)    {        std::lock_guard<std::mutex> lck(mtx);        std::cout << value1 << ';' << value2 << ';' << value3 << '\n';    }Just because you release the lock does not mean waiting threads are guranteed to be the first thread that is given the lock next. It is just as likely that this thread will regain the lock again when it re-enters the loop.You should be using condition variables to force an ordering.