   Threading Data Sharing(Solved)
  Back with more threading problems:Okay I have two threads , each are both basically two loops.They are both operating on the same data list. Now, each element in the list has a critical section like so:me[x]->Edit(); //enter critical section// do stuff to meme[x]->DoneEdit(); // leavethe problem is I think that Thread1 has not sent it's me[x] back into memory, even after it leaves the critical section. And while Thread2 is operating on it, Thread1 writes to memory. How can I make sure that both these threads can operate on the same data? Without locking out the whole list?Thanks again[Edited by - MetaKnight on June 1, 2006 2:13:37 PM]
  Try making m[x] volatile by using the volitile keyword. This will keep the compiler from doing some optimizations like you describe   ;  Hmmm, I kinda doubt making it volatile is going to solve his problem. In fact I doubt it has anything to do with one of the threads not having written its data back to memory, but it's hard to see what might be causing this unless you post the relevant code here. I'd be interested to see the actual loops as well as the implementations of the Edit() and DoneEdit() methods.   ;Quote:Original post by MetaKnightHow can I make sure that both these threads can operate on the same data? Without locking out the whole list?Your threads are not changing the list itself, only the elements contained therein, right? If so, mutex-protecting the whole list isn't going to do anything for you since you've already given the individual list elements mutex protection.;  According to this that's exactly what volatile would do (in the given example). Other than that though I have no other ideas, I'm not really a multithreaded programmer.   ;Quote:Original post by MetaKnightme[x]->Edit(); //enter critical section// do stuff to meme[x]->DoneEdit(); // leaveThis is one of the most important uses of the RAII idiom.class Locker {public:  Locker(Me& me)  : m_me(me)  { m_me.Edit(); }  ~Locker()  { m_me.DoneEdit(); }private:  Me& m_me;};// somewhere in code  {    Locker lock(*me[x]);    // .. do something with me  } // guaranteed critical section release;  Correct.critical section good solutionKuphryn   ;Quote:Original post by perfectly_darkAccording to this that's exactly what volatile would do (in the given example). Other than that though I have no other ideas, I'm not really a multithreaded programmer.From the article you posted:Quote:In short, data shared between threads is conceptually volatile outside a critical section, and non-volatile inside a critical section.There you have it. If you're correctly using mutex-protection, there is no way your variable can somehow get corrupted by another thread. Shared data may very well be volatile in nature outside of critical sections, but who cares? If you're in any way accessing shared data outside a critical section then you're doing something that you MUST not do, and your program is simply incorrect. IMHO.   ;  okay I took out all the weird parts of my code and ran this, and it still has the same problem so here is the data for each thread:this is what edit and done-edit look likegameNode::gameNode() {InitializeCriticalSection(&mySection);}void gameNode::Edit(){EnterCriticalSection(&mySection);}void gameNode::DoneEdit(){LeaveCriticalSection(&mySection);}this is what the first thread basicaly looks likegameNode *gameRunner = NULL;for(list<gameNode*>::iterator iter = gameList.begin();iter != gameList.end();iter++){gameRunner =  (*iter);gameRunner->Edit();gameRunner->Run();gameRunner->DoneEdit();}and the other thread looks the same except insted of ->Run is ->DrawNow when I try to make gameNode *gameRunner = NULL; intovolatile gameNode *gameRunner = NULL;but then each funtion gets an error like so:error C2662: 'gameNode::DoneEdit' : cannot convert 'this' pointer from 'volatile gameNode' to 'gameNode &'error C2662: 'gameNode::Edit' : cannot convert 'this' pointer from 'volatile gameNode' to 'gameNode &'error C2662: 'gameNode::Run' : cannot convert 'this' pointer from 'volatile gameNode' to 'gameNode &'Ive never had to use volatile before, I have always issumed that Critial section took care of this for me.;Quote:There you have it. If you're correctly using mutex-protection, there is no way your variable can somehow get corrupted by another thread. Shared data may very well be volatile in nature outside of critical sections, but who cares? If you're in any way accessing shared data outside a critical section then you're doing something that you MUST not do, and your program is simply incorrect. IMHO.Ah, I understand now. As I said, I'm not really a multithreaded programmer [grin]   