ITickable and thread safety (continued)

#1 In Torque on win32, no secondary threads occur that I know of (there are other threads running but they're made by DirectInput and OpenAL among other things - they should not be running Torque code). So what could be changing things on you? I don't know. Maybe would be a good idea to put a breakpoint on the ITickable constructor and see when it's getting called. Same for destructor.

For your change on the destructor, you need to lock the mutex around ANY access to the process list - not just when you change it. Small changes tend to be atomic anyway (depending on many many variables - don't write code that assumes this unless you like having things crash randomly!) - the larger issue is when you read something, it's changed, and then you write back.

#2 I've done a whole lot of debugging on this issue and I know for a fact that the process list grows simultaneously with advanceTime being executed. The size of the list is larger when it crashes than when it enters advanceTime. The only way I can see this happening is if code is executed in different threads. The only place where the process list is added to is in the tickable constructor.

I don't think I understand what you mean about the mutex and atomic changes. Should I move the locking to before the iteration starts? There are no other places where the process list i being accessed than the constructor, destructor and advanceTime.

I really appreciate your answers Ben!

#3

Quote:
The only way I can see this happening is if code is executed in different threads.

Well, no, not necessarily.

You could be growing or shrinking the process list in some other routine that is running as a result of "advanceTime" being called on one of your ITickables.

Have you double-checked all your advanceTime/processTick implementations to make sure they are benign?

Just a guess...

#4 Yeah - stick a breakpoint in the ITickable ctor/dtor - under visual studio it'll break properly even if other threads hit it. Then just hit F5 till you see a insert happening during advance time.

#5 I feel stupid. Of course that's how it is. The animation is updated in advanceTime on a tickable object -> the trigger is hit -> a new tickable object is created -> list is updated and corrupted. I worked around it by pushing an event. Problem solved (I hope). Thanks for the help guys!

#6 That's the way to go. Glad you got it fixed. :)

#7 Eh... maybe just a lucky guess on my part because I'd bitten myself in the same way before. :)

Glad you found your problem!