   [Winsock2] Safe thread termination
  Hello GameDevs !I am fairly new to network programming and so I wanted to ask you for some advice concerning threads before doing something potentially stupid.I have this class CNetServer that holds a static member function that runs like a thread and gets a reference to the server passed on upon start. The thread will run as long as a member bool m_bIsRunning of the server is true. What concerns me however is if I delete the server instance (using delete), even if I set the bool to false first, there is a risk that the thread will attempt to read the bool _after_ the deletion.class CNetServer{public:CNetServer();~CNetServer() { Release(); }BOOL Initialize();void Release();void Update();private:static DWORD WINAPI RunThread( LPVOID lpParam );WSADATAm_winsock;SOCKETm_socket;sockaddr_inm_serverAddress;BOOLm_bIsRunning;};BOOL CNetServer::Initialize(){...CreateThread( NULL, 0, RunThread, this, 0, NULL );...return TRUE;}DWORD WINAPI CNetServer::RunThread( LPVOID lpParam ){CNetServer* pServer = (CNetServer*)lpParam;while( pServer && pServer->m_bIsRunning ){...}return 0;}So my question is: is this really a problem and if so how might I get around it?Many thanks in advance !- Dave   
  hasty reply:Set it to falseDo a join on the thread (googles it)delete after join returns-me   ;  I can only assume this is a Winsock equivalent solution, if anyone would like to confirm this I would very much appreciate it :)void CNetwork::CNetServer::Release(){m_bIsRunning = FALSE;while( WaitForSingleObject( m_hRunThread, 0 ) != WAIT_OBJECT_0 ){// Wait for thread to terminate}};  The short answer is that, if your design allows that problem, then your design is broken.;  While I appreciate you guys taking the time to read my thread, it hasn't helped me very much. I am already capable of surmising when I might have a design flaw (wouldn't have made the thread otherwise) but being new at this it is a bit more precise advice I need.   ;  What other resources have you looked at? Have you compared the asynchronous design of boost::asio? Have you looked at the Intel threading resources? What other class libraries or thread APIs have you used? (pthreads, MFC, etc)The simplest thing to do to get a fully "safe" system is to introduce reference counting (boost::shared_ptr<> is one way of doing that), and make the thread that executes into the object own a reference to the object. The object could then not die until the thread object died.Another option is for the object to know about the thread -- maybe even own the thread. The object would then set the "die" flag and wait for the thread to terminate inside its destructor. This ensures that the object will stay alive for as long as the thread does. It will also create a deadlock if you try to delete the object from within the thread! (Your "release" handler has the same problem, and won't solve a "delete" as opposed to a "release" operation)In general, lifetime issues, ownership issues and especially stopping/tear-down issues are where threaded design starts departing from plain and simple "OO" design. I highly recommend getting some exposure to a number of different ways of doing it using books, frameworks and available open source software as reference. It's not something where you can just say "hey, do this" and it's done.I also like to say that a simple boolean for whether the thread is running isn't generally sufficient. A thread will either be compute bound, at which point it won't have time to check the "is running" flag very often, or it will be I/O bound, which means it shouldn't check the flag in a spin loop, but instead block on some kernel primitive (like an event in Win32). Thus, at a minimum, you'll generally want to combine the "running" flag, and any other message going to the thread, with an even that you can set after putting in the message, so the thread can immediately wake up and check the message.;  If you want to avoid most of the hassles of threaded design, consider using asynchronous I/O. It allows you to do I/O on multiple sockets without threads. Your application can even do other processing in parallel to socket I/O without ever using more than one thread.If you really want to use Winsock2 directly, then look up "overlapped I/O" in the documentation. This is what Microsoft calls asynchronous I/O.You may also have a look at the Proactor pattern and at boost::asio before you start your own design. Or you can use boost::asio right away.If you decide to go for async I/O in your server, consider doing the same in your client as well. Blocking synchronous I/O, although cheap to implement, is almost always the wrong solution. In a single-threaded client application, it may ruin the user experience, especially in situations with high network latency.I'm not arguing that async I/O with a single-threaded design is the best and most efficient solution. All I'm saying is that it is one way to avoid using threads. Proper multi-threaded programming may take years to learn, and I see you are new to it. If you just want to get the job done, and you can get it done without using threads, then go for it.   ;  Thanks guys, that does give me a bit better idea of what I'm delving into. I will look into the suggested solutions now that you have helped narrow the enormous information area down to the relevance of my problem :)   