C++ Static Class member refers to self

I'm curious as to whether this is something that I can do:

using namespace tthread;
class E_thread {
    static std::list<E_thread*> all_threads;
    thread th;
    E_messageQueue queue;
public:
    E_thread(void (*threadFunction)(void *), void * threadFuncArg) {
        all_threads.push_back(this);
        th = thread(threadFunction,threadFuncArg);
    }
 开发者_开发知识库   ~E_thread() {
        queue.push_terminate_thread_message();
        th.join();
        all_threads.remove(this);
    }
};

My intention is to make it easy for any thread to spawn new threads or to send messages to another thread, and the thread list also is capable of cleaning up after itself. As far as I understand it I could replace all_threads with a global std::list<E_thread*> which serves the same purpose if I wanted to, but isn't this a cleaner method of getting that sort of "globalness"?

What's a little uneasy about this is that I haven't forced my new threads to have a message reading loop, to be able to handle the terminate message.

---

This is fine, mostly. You need to protect access (reading or modifying both) to all_threads with a mutex of some sort. Also, you would be better served to use a ::std::set if you destroy threads often during the course of your program.

Also, I sort of question having global variables of any kind. I think it would be cleaner if you had a 'thread manager' object that you passed in what you created a thread, or maybe a thread factory that kept track of all the threads it created.

Global variables make programs much harder to test, and make them more brittle and less capable of being modified later.

---

• undefined behaviour on some OS if multiple threads attempt to join the same thread

• all_threads needs to be protected by a mutex for the push_back, remove, and any other reader that may try to iterate over it

  • you may want to include modifications to th in the mutex-protected block if other threads iterating all_threads may try to do something to th before or during its assignment

• this has a tendency to serialise thread destruction, as push_terminate_thread_message is sent to a single thread, then a join is done. It's generally better to send all the termination messages then do all the joins.

• it's not obvious to me how the threads are supposed to know about the queues, though the threadFuncArg might be abused for this in some limited circumstances

Omnifarious's suggestion of a proper thread pool is much more appealing.