   Two threads accessing same memory
  Hi there!I have a fairly easy question about multithreading, let me demonstrate it with some code.DWORD WINAPI ThreadFunc(LPVOID pParam){   bool *pExitFlag = reinterpret_cast<bool*)(pParam);   while (true) { //initialize some memory, this needs to be removed //before the end of the thread char *pMemory = new char[1000]; //do all kinds of stuff, in a loop //sleep a little too, not to hog up resources Sleep(250); if (*pExitFlag) {    delete [] pMemory;    return 0; }   }}ThreadManagerClass::~ThreadManagerClass(){   m_bExitFlag = true;   DWORD dwReturn = WaitForSingleObject(threadHandle, 10000);   if (dwReturn == WAIT_TIMEOUT) { //force it anyway TerminateThread(threadHandle, 1);   }}The problem is: there could be a certain situation, where the thread itself would be looking up the value of bExitFlag in a ThreadManager class, and the class destructor would be setting the flag of bExitFlag at the same time.Should I add a mutex to the thread function and the thread manager for reading and writing the value of bExitFlag? Or should nothing bad happen? The reason I ask is: A lot of threads will be accessing this class, and I don't want it to block every few milliseconds.Thanks in advance,Max Henger   
  In order to maintain a consistent view of variables between threads, you might want to look into the Interlocked functions provided by the windows API - in particular, InterlockedCompareExchange.You can use that to completely avoid any locking in your example (I think).   ;Quote:Original post by MadMax1992Hi there!I have a fairly easy question about multithreading, let me demonstrate it with some code.*** Source Snippet Removed ***The problem is: there could be a certain situation, where the thread itself would be looking up the value of bExitFlag in a ThreadManager class, and the class destructor would be setting the flag of bExitFlag at the same time.Should I add a mutex to the thread function and the thread manager for reading and writing the value of bExitFlag? Or should nothing bad happen? The reason I ask is: A lot of threads will be accessing this class, and I don't want it to block every few milliseconds.Thanks in advance,Max HengerIn this case, it's fine. The value can either be true or false, it can't be anything inbetween. If you were writing to the variable from more than one thread, there'd be a problem.Personally, I'd create an event (With CreateEvent()) which I signal from the main thread to mean "All threads should terminate now"). You can then SetEvent() on that event, and wait for all threads to end.   ;  Thank you very much for both of your replies   ;  In this example, the worst thing that can happen is that your threads run an extra cycle or two.However, just because this works doesn't mean that you can use shared memory without locking in general. It is thoroughly possible that the compiler (or even the CPU) will do things in an order you would not expect, therefore causing your code to misbehave. For example, without a proper memory fence, you might get the value of a variable from one CPU's cache while another CPU is in the process of writing to that value. In this case you may run on "stale" data for quite some time before things rectify themselves; but chances are you'll crash hard before that happens.So please don't rely on this kind of behaviour in general - you still need to lock (or do very difficult lock-free algorithms) in virtually all cases [smile]   ;  Well, I have a mutex on accessing the thread manager on other occasions (such as reporting an error, reporting succes etc.) but I wondered if I had to do it if only one thread wrote to a certain variable.I think I'll still go with the event-code EvilSteve wrote about. It seems like the most elegant thing to do...   ;Quote:In this case, it's fine. The value can either be true or false, it can't be anything inbetween. If you were writing to the variable from more than one thread, there'd be a problem.Due to instruction re-ordering both by your compiler as well as your hardware, you could still have issues, still unsafe :PEdit: err yeah i missed  ApochPiQ's post - listen to him he knows (:   